Re: [Lift] Customizing meta fields
No problem. Let us know if you have any more questions.
-Ross
On Mar 8, 2010, at 2:09 PM, Martin Dale Lyness wrote:
> 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 wrote:
> For your particular example, you can use head merge as Naftoli suggests. Head
> merge is a behavior of Lift templates where any 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 name="foobar" /> and then define what to put there in the surrounded template
> using the content
>
> 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 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:
>> This site is totally awesome, better than all our
>> competitors in index.html
>> Look at all these products in
>> %%category_name%%in product_list.html
>> %product_name% - %product_description%
>>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.
>> 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 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 wrote:
>> To be parsed by the bind, it must be enclosed by
>> ...
>>
>> 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:
>>
>>
>>
>> class HelloWorld {
>>
>>def meta_desc(ns
Re: [Lift] Customizing meta fields
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 wrote:
> For your particular example, you can use head merge as Naftoli suggests.
> Head merge is a behavior of Lift templates where any 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 name="foobar" /> and then define what to put there in the surrounded
> template using the content
>
> 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 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:
> This site is totally awesome, better than all our
> competitors in index.html
> Look at all these products in
> %%category_name%%in product_list.html
> %product_name% - %product_description%
> 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. 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 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 wrote:
>
>> To be parsed by the bind, it must be enclosed by
>> ...
>>
>> 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:
>>
>>
>>
>> class HelloWorld {
>>
>>def meta_desc(ns: NodeSeq): NodeSeq = Text("test desc")
>>
>> }
>>
>> Which will result in this XHTML:
>>
>> test desc
>>
>> Or, if you want to keep it in the hello method, you'd then have to move
>> the to the outside of the template:
>>
>>
>> ...
>>
Re: [Lift] Customizing meta fields
For your particular example, you can use head merge as Naftoli suggests. Head
merge is a behavior of Lift templates where any 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 and then define what to put there in the surrounded template
using the content
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 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:
> This site is totally awesome, better than all our
> competitors in index.html
> Look at all these products in
> %%category_name%%in product_list.html
> %product_name% - %product_description%
> 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.
> 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 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 wrote:
> To be parsed by the bind, it must be enclosed by
> ...
>
> 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:
>
>
>
> class HelloWorld {
>
>def meta_desc(ns: NodeSeq): NodeSeq = Text("test desc")
>
> }
>
> Which will result in this XHTML:
>
> test desc
>
> Or, if you want to keep it in the hello method, you'd then have to move the
> to the outside of the template:
>
>
> ...
>
>
>
>...
>
>
>
> 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
> >
> >
> > HelloWorld.scala
> > H
Re: [Lift] Customizing meta fields
It's not necessary. Just put a head section in the template and it will be
combined with the head section in default.html.
-
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 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:
This site is totally awesome, better than all our
competitors in index.html
Look at all these products in
%%category_name%%in product_list.html
%product_name% - %product_description%
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. 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 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 wrote:
> To be parsed by the bind, it must be enclosed by
> ...
>
> 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:
>
>
>
> class HelloWorld {
>
>def meta_desc(ns: NodeSeq): NodeSeq = Text("test desc")
>
> }
>
> Which will result in this XHTML:
>
> test desc
>
> Or, if you want to keep it in the hello method, you'd then have to move the
> to the outside of the template:
>
>
> ...
>
>
>
>...
>
>
>
> 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
> >
> >
> > 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
Re: [Lift] Customizing meta fields
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 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:
This site is totally awesome, better than all our
competitors in index.html
Look at all these products in
%%category_name%%in product_list.html
%product_name% - %product_description%
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. 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 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 wrote:
> To be parsed by the bind, it must be enclosed by
> ...
>
> 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:
>
>
>
> class HelloWorld {
>
>def meta_desc(ns: NodeSeq): NodeSeq = Text("test desc")
>
> }
>
> Which will result in this XHTML:
>
> test desc
>
> Or, if you want to keep it in the hello method, you'd then have to move the
> to the outside of the template:
>
>
> ...
>
>
>
>...
>
>
>
> 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
> >
> >
> > 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
Re: [Lift] Customizing meta fields
To be parsed by the bind, it must be enclosed by
...
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:
class HelloWorld {
def meta_desc(ns: NodeSeq): NodeSeq = Text("test desc")
}
Which will result in this XHTML:
test desc
Or, if you want to keep it in the hello method, you'd then have to move the
to the outside of the template:
...
...
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
>
>
> 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.
[Lift] Customizing meta fields
How would one go about having dynamic description and keyword meta
tags in a template? Here is what i've tried:
default.html
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.
