Re: [Lift] Customizing meta fields

2010-03-08 Thread Martin Dale Lyness
Again, thank you so much for the help! The head merge feature is perfect for
this situation i described and my next line of though is right inline with
how you describe bind points!

Thanks again!

-- Martin

On Mon, Mar 8, 2010 at 12:47 PM, Ross Mellgren dri...@gmail.com wrote:

 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=foobarthe 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_descThis site is totally awesome, better than all our
 competitors/lift:meta_desc   in index.html
 lift:meta_descLook at all these products in
 %%category_name%%/lift:meta_descin 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=descriptionlift:HelloWorld.meta_desc //meta

 class HelloWorld {

def meta_desc(ns: NodeSeq): NodeSeq = Text(test desc)

 }

 Which

Re: [Lift] Customizing meta fields

2010-03-07 Thread Martin Dale Lyness
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_descThis site is totally awesome, better than all our
competitors/lift:meta_desc   in index.html
lift:meta_descLook at all these products in
%%category_name%%/lift:meta_descin 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=descriptionlift:HelloWorld.meta_desc //meta

 class HelloWorld {

def meta_desc(ns: NodeSeq): NodeSeq = Text(test desc)

 }

 Which will result in this XHTML:

 meta name=descriptiontest 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=descriptionb: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=descriptionb: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