For your particular example, you can use head merge as Naftoli suggests. Head
merge is a behavior of Lift templates where any <head> tags will be merged
together for the final output, so you put your meta name="description" in each
of the specific places, any general head stuff you want in your surrounding
template and they will magically get folded together at render time.
For other cases, you have a couple tools at your disposal:
- RequestVars -- variables that are local to a particular page request. You
can use these inside snippets to capture and recover values during template
processing.
- Bind points. In a surrounding template you can use tags like <lift:bind
name="foobar" /> and then define what to put there in the surrounded template
using <lift:bind-at name="foobar">the content</lift:bind-at>
And there are more. Hopefully head merging will work for you in this case.
-Ross
On Mar 7, 2010, at 8:25 PM, Martin Dale Lyness wrote:
> 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.
> > 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.
>
>
>
> --
> 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.
--
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.
