Thank you Ross, for the very informative response!

Now, I consider SEO to be closer to a designer task than a developer task so
keeping the power in the design documents would be my best idea. Is there
anyway to allow individual pages to define blocks that are read into the
snippets and then injected into the template?

Here is the scenario i'm thinking of:
1. A single uniform website template: default.html
2. Several HTML files: index.html, product_list.html, product_overview.html
3. Each of these HTML files containing <lift:xxx> tags referencing snippets.

What i would want is for index.html, product_list.html, and
product_overview.html to all use default.html and various Snippet classes.
Now for SEO i would want the meta tags in the header of default.html to be
customized to index.html, product_list.html, and product_overview.html;
furthermore, product_list and product_overview are dynamic pages so they
would need further customization based on what the snippets are returning.

Essentially, i would want tags something like:
<lift:meta_desc>This site is totally awesome, better than all our
competitors</lift:meta_desc>   in index.html
<lift:meta_desc>Look at all these products in
%%category_name%%</lift:meta_desc>            in product_list.html
<lift:meta_desc>%product_name% - %product_description%</lift:meta_desc>
                    in product_overview.html

The conceptual road block for me is coming from the controller first pattern
used in frameworks like Rails. In lift snippets are not really the same
conceptually. If i use the second proposed method
(i.e. <lift:HelloWorld.hello> wrapping the entire template) i would have a
battle between snippets used by each page. For example, perhaps i have a
product overview snippet that sets the meta one way and a login snippet that
sets it another way (intended for when show standalone in a login.html).

The first solution with using a <lift:HelloWorld.funcName /> to inject a
snippet at a meta location fits better because it would allow me to create a
generic function that would attempt to create the keyword and description
data based on whatever global information is made available to snippets by
lift (i.e. Request Parameters?). My only problem with using this option is
it puts all of the text on the developer side forcing the dev team to update
descriptions and keywords where really the designers should be doing this.

Does anyone have a suggestion on how to put the power in the hands of the
designers in this type of situation?

-- Martin

On Sun, Mar 7, 2010 at 6:17 PM, Ross Mellgren <dri...@gmail.com> wrote:

> To be parsed by the bind, it must be enclosed by
> <lift:HelloWorld.hello>...</lift:HelloWorld.hello>
>
> There is relatively little magic -- Lift goes through your template looking
> for lift: prefixed tags. For those tags, it will look up a snippet class by
> using the part before the period (HelloWorld, in the above example) and then
> look for a method on that snippet class mentioned after the period (hello in
> the example). If there is no period, the method is assumed to be called
> "render".
>
> Once that method is found, the method is called with the contents of the
> lift: tag, and the result of the method call is spliced into the XML to
> replace the lift: tag.
>
> bind is a function that does something kind of similar to overall template
> processing, except you supply some prefix other than lift: (b: in the
> example) and a limited set of things after the colon that are valid (time
> and meta_desc in the example)
>
> So, you might want something like this instead:
>
> <meta name="description"><lift:HelloWorld.meta_desc /></meta>
>
> class HelloWorld {
>    ....
>    def meta_desc(ns: NodeSeq): NodeSeq = Text("test desc")
>    ....
> }
>
> Which will result in this XHTML:
>
> <meta name="description">test desc</meta>
>
> Or, if you want to keep it in the hello method, you'd then have to move the
> <lift:HelloWorld.hello> to the outside of the template:
>
> <lift:HelloWorld.hello>
>   ...
>   <head>
>         <meta name="description"><b:meta:desc /></meta>
>     </head>
>    ...
>    <b:time />
> </lift:HelloWorld.hello>
>
> Hope that helps,
> -Ross
>
>
> On Mar 7, 2010, at 4:38 AM, Martin wrote:
>
> > How would one go about having dynamic description and keyword meta
> > tags in a template? Here is what i've tried:
> >
> > default.html
> > <meta name="description"><b:meta_desc /></meta>
> >
> > HelloWorld.scala
> > Helpers.bind("b", in, "time" -> date.map(d => Text(d.toString)),
> > "meta_desc" -> "test desc")
> >
> > I'm using a basic archetype build of 2.0-M3 and it produces an error:
> >
> > This page contains the following errors:
> >
> > error on line 6 at column 28: Namespace prefix b on meta_desc is not
> > defined
> > Below is a rendering of the page up to the first error.
> >
> >
> > It appears to me that the template is not parsed by the Helpers.bind,
> > is this correct?
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com>
> .
> > For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Reply via email to