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 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 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
...
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 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
[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 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 liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Customizing meta fields
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
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.
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 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
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 Lynessmartin.lyn...@gmail.com 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 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
