[Lift] Re: lift:with-params deprecation alternatives
I tried to find some info about the correct usage of template related
tags on wiki but I couldn't find the most recent information about it.
I'm starting with Lift and I couldn't find all information that I want
on wiki pages, is there any chance to update the wiki with some info
about these renamed tags?
On 20 ago, 14:18, inca incarn...@whiteants.net wrote:
The neat thing about the insert is that it is consistent with other
templating frameworks (Tiles [http://struts.apache.org/1.x/struts-
tiles/tlddoc/tiles/insert.html], Facelets [http://www.roseindia.net/
jsf/insert.shtml], etc.), so it would be easy for folks like me to
migrate to Lift. I don't think that lift:bind-at is a good
replacement: it looks very similar to lift:bind when browsing the
code (I've just tested this, not very eye-catching difference).
And if you really like minimal typing, call it lift:put at= (it is
one letter smaller than lift:at name=) :) And yes, it's naming
policy is still consistent with other tags (verbs as tag names and
pronouns as attributes).
About the built-in snippet aliases... I don't see anything wrong
there. Just let them have custom xml prefixes, and it would be
perfectly clear that it is an alias. I, personally, think that xml
prefixes are great. Say I have a snippet like this:
class HtmlUI {
def wrapper(in:NodeSeq):NodeSeq =
div class=w
div class=e
div class=c{in}
/div
/div
/div
def button(in:NodeSeq):NodeSeq =
a class=button
style={background:transparent url('/img/buttons/bkg- + S.attr
(bkg).openOr(green) + .png') no-repeat}
title={S.attr(title).openOr()}
href={S.attr(href).openOr(#)}
img src={/img/buttons/ + S.attr(icon).openOr() + .png}
alt=/
div class=gloss/
/a
...etc...
}
So every time I need a wrapper or a glossy button I would write
lift:HtmlUI.wrapper ... or lift:HtmlUI.button
Now if I had a chance to create xhtml prefix alias for this snippet
(something like that:
LiftRules.addSnippetMapping(ui - HtmlUI)
), than my xhtml templates would reduce a lot (ui:wrapper ... and
ui:button ...) along with increased readability.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@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] Re: lift:with-params deprecation alternatives
Currently both with-param and bind-at are supported. I'll try to
update the wiki.
Br's,
Marius
On Aug 23, 5:28 pm, _rogerio_ rogerio.ara...@gmail.com wrote:
I tried to find some info about the correct usage of template related
tags on wiki but I couldn't find the most recent information about it.
I'm starting with Lift and I couldn't find all information that I want
on wiki pages, is there any chance to update the wiki with some info
about these renamed tags?
On 20 ago, 14:18, inca incarn...@whiteants.net wrote:
The neat thing about the insert is that it is consistent with other
templating frameworks (Tiles [http://struts.apache.org/1.x/struts-
tiles/tlddoc/tiles/insert.html], Facelets [http://www.roseindia.net/
jsf/insert.shtml], etc.), so it would be easy for folks like me to
migrate to Lift. I don't think that lift:bind-at is a good
replacement: it looks very similar to lift:bind when browsing the
code (I've just tested this, not very eye-catching difference).
And if you really like minimal typing, call it lift:put at= (it is
one letter smaller than lift:at name=) :) And yes, it's naming
policy is still consistent with other tags (verbs as tag names and
pronouns as attributes).
About the built-in snippet aliases... I don't see anything wrong
there. Just let them have custom xml prefixes, and it would be
perfectly clear that it is an alias. I, personally, think that xml
prefixes are great. Say I have a snippet like this:
class HtmlUI {
def wrapper(in:NodeSeq):NodeSeq =
div class=w
div class=e
div class=c{in}
/div
/div
/div
def button(in:NodeSeq):NodeSeq =
a class=button
style={background:transparent url('/img/buttons/bkg- + S.attr
(bkg).openOr(green) + .png') no-repeat}
title={S.attr(title).openOr()}
href={S.attr(href).openOr(#)}
img src={/img/buttons/ + S.attr(icon).openOr() + .png}
alt=/
div class=gloss/
/a
...etc...
}
So every time I need a wrapper or a glossy button I would write
lift:HtmlUI.wrapper ... or lift:HtmlUI.button
Now if I had a chance to create xhtml prefix alias for this snippet
(something like that:
LiftRules.addSnippetMapping(ui - HtmlUI)
), than my xhtml templates would reduce a lot (ui:wrapper ... and
ui:button ...) along with increased readability.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@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] Re: lift:with-params deprecation alternatives
I will add lift:insert support .. personally I don't feel very comfortable allowing builtin snippets to have different names. One case I'm thinking of that people may change them, post issues on the list and we'd have o idea what the user really uses which may lead to longer discussions and support. I've learned my lesson with over- customization of things; it can bring real pains sometimes. Just my 2 cents ... Br's, Marius On Aug 20, 4:09 pm, inca incarn...@whiteants.net wrote: Yes, David, that's wonderful idea, too. Should eliminate many headaches. On 20 авг, 01:59, David Pollak feeder.of.the.be...@gmail.com wrote: On Wed, Aug 19, 2009 at 2:46 AM, marius d. marius.dan...@gmail.com wrote: This is a decision that needs consensus ... and David's agreement. I'm cool with it. It might also be worth thinking about creating some alias library so folks could change the default names of Lift's snippets. Or maybe that's just a bad idea. Personally I agree with it but others may not. Br's, Marius On Aug 19, 12:41 pm, inca incarn...@whiteants.net wrote: Why not just introduce the new tag, leaving the former alone (possibly deprecated in next major releases)? On 19 авг, 12:07, marius d. marius.dan...@gmail.com wrote: Yes we tried to deprecate it but later on we un-derprecate it :) So you can use lift:with-param safely. Purely for naming perspective lift:insert seems to me more intuitive than lift:with-param ... I'm not sure if this is a strong enough motivation to change the name hence inducing a breaking change. Br's, Marius On Aug 19, 10:55 am, inca incarn...@whiteants.net wrote: As suggested inhttp:// groups.google.com/group/liftweb/browse_thread/thread/d664b712d... by Mr. Marius D., I should use lift:with-param in order to insert content into multiple bind points of template. But recently I read that this tag is deprecated. What alternatives are available? P.S. I would propose lift:insert at=bindPointName tag for this purpose. And the contents of lift:bind name=bindPointName tag should be assumed as default if none lift:insert ... tag overrides it. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] Re: lift:with-params deprecation alternatives
Yes, David, that's wonderful idea, too. Should eliminate many headaches. On 20 авг, 01:59, David Pollak feeder.of.the.be...@gmail.com wrote: On Wed, Aug 19, 2009 at 2:46 AM, marius d. marius.dan...@gmail.com wrote: This is a decision that needs consensus ... and David's agreement. I'm cool with it. It might also be worth thinking about creating some alias library so folks could change the default names of Lift's snippets. Or maybe that's just a bad idea. Personally I agree with it but others may not. Br's, Marius On Aug 19, 12:41 pm, inca incarn...@whiteants.net wrote: Why not just introduce the new tag, leaving the former alone (possibly deprecated in next major releases)? On 19 авг, 12:07, marius d. marius.dan...@gmail.com wrote: Yes we tried to deprecate it but later on we un-derprecate it :) So you can use lift:with-param safely. Purely for naming perspective lift:insert seems to me more intuitive than lift:with-param ... I'm not sure if this is a strong enough motivation to change the name hence inducing a breaking change. Br's, Marius On Aug 19, 10:55 am, inca incarn...@whiteants.net wrote: As suggested inhttp:// groups.google.com/group/liftweb/browse_thread/thread/d664b712d... by Mr. Marius D., I should use lift:with-param in order to insert content into multiple bind points of template. But recently I read that this tag is deprecated. What alternatives are available? P.S. I would propose lift:insert at=bindPointName tag for this purpose. And the contents of lift:bind name=bindPointName tag should be assumed as default if none lift:insert ... tag overrides it. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] Re: lift:with-params deprecation alternatives
Well the way I see it is lift:insert at= .. So the semantic would always be insert-at .. such as insert this markup at this bind position... which in essence is an insert operation that makes a lot of sense - to me at least. On the other hand lift:embed embeds a template into *this* position so there is no *at* semantic. So the way I see it the two don't step on each other toes. Br's, Marius On Aug 20, 4:34 pm, Timothy Perrett timo...@getintheloop.eu wrote: Can I just make an objection to calling it insert - IMO, that's a conflict with the language semantic of embed - I agree with-param is not ideal, but im not sure that insert is ideal either. I also agree with marius, what would you suggest to resolve this issue? I tried to post yesterday but it looks like my mail didn't make it into the group. Cheers, Tim On 20/08/2009 14:15, marius d. marius.dan...@gmail.com wrote: I will add lift:insert support .. personally I don't feel very comfortable allowing builtin snippets to have different names. One case I'm thinking of that people may change them, post issues on the list and we'd have o idea what the user really uses which may lead to longer discussions and support. I've learned my lesson with over- customization of things; it can bring real pains sometimes. Just my 2 cents ... Br's, Marius On Aug 20, 4:09 pm, inca incarn...@whiteants.net wrote: Yes, David, that's wonderful idea, too. Should eliminate many headaches. On 20 авг, 01:59, David Pollak feeder.of.the.be...@gmail.com wrote: On Wed, Aug 19, 2009 at 2:46 AM, marius d. marius.dan...@gmail.com wrote: This is a decision that needs consensus ... and David's agreement. I'm cool with it. It might also be worth thinking about creating some alias library so folks could change the default names of Lift's snippets. Or maybe that's just a bad idea. Personally I agree with it but others may not. Br's, Marius On Aug 19, 12:41 pm, inca incarn...@whiteants.net wrote: Why not just introduce the new tag, leaving the former alone (possibly deprecated in next major releases)? On 19 авг, 12:07, marius d. marius.dan...@gmail.com wrote: Yes we tried to deprecate it but later on we un-derprecate it :) So you can use lift:with-param safely. Purely for naming perspective lift:insert seems to me more intuitive than lift:with-param ... I'm not sure if this is a strong enough motivation to change the name hence inducing a breaking change. Br's, Marius On Aug 19, 10:55 am, inca incarn...@whiteants.net wrote: As suggested inhttp:// groups.google.com/group/liftweb/browse_thread/thread/d664b712d... by Mr. Marius D., I should use lift:with-param in order to insert content into multiple bind points of template. But recently I read that this tag is deprecated. What alternatives are available? P.S. I would propose lift:insert at=bindPointName tag for this purpose. And the contents of lift:bind name=bindPointName tag should be assumed as default if none lift:insert ... tag overrides it. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] Re: lift:with-params deprecation alternatives
Can I just make an objection to calling it insert - IMO, that's a conflict with the language semantic of embed - I agree with-param is not ideal, but im not sure that insert is ideal either. I also agree with marius, what would you suggest to resolve this issue? I tried to post yesterday but it looks like my mail didn't make it into the group. Cheers, Tim On 20/08/2009 14:15, marius d. marius.dan...@gmail.com wrote: I will add lift:insert support .. personally I don't feel very comfortable allowing builtin snippets to have different names. One case I'm thinking of that people may change them, post issues on the list and we'd have o idea what the user really uses which may lead to longer discussions and support. I've learned my lesson with over- customization of things; it can bring real pains sometimes. Just my 2 cents ... Br's, Marius On Aug 20, 4:09 pm, inca incarn...@whiteants.net wrote: Yes, David, that's wonderful idea, too. Should eliminate many headaches. On 20 авг, 01:59, David Pollak feeder.of.the.be...@gmail.com wrote: On Wed, Aug 19, 2009 at 2:46 AM, marius d. marius.dan...@gmail.com wrote: This is a decision that needs consensus ... and David's agreement. I'm cool with it. It might also be worth thinking about creating some alias library so folks could change the default names of Lift's snippets. Or maybe that's just a bad idea. Personally I agree with it but others may not. Br's, Marius On Aug 19, 12:41 pm, inca incarn...@whiteants.net wrote: Why not just introduce the new tag, leaving the former alone (possibly deprecated in next major releases)? On 19 авг, 12:07, marius d. marius.dan...@gmail.com wrote: Yes we tried to deprecate it but later on we un-derprecate it :) So you can use lift:with-param safely. Purely for naming perspective lift:insert seems to me more intuitive than lift:with-param ... I'm not sure if this is a strong enough motivation to change the name hence inducing a breaking change. Br's, Marius On Aug 19, 10:55 am, inca incarn...@whiteants.net wrote: As suggested inhttp:// groups.google.com/group/liftweb/browse_thread/thread/d664b712d... by Mr. Marius D., I should use lift:with-param in order to insert content into multiple bind points of template. But recently I read that this tag is deprecated. What alternatives are available? P.S. I would propose lift:insert at=bindPointName tag for this purpose. And the contents of lift:bind name=bindPointName tag should be assumed as default if none lift:insert ... tag overrides it. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] Re: lift:with-params deprecation alternatives
How about lift:bind-to name=.../ which works with lift:bind .../ I'm also open to non-English words that mean the same (as long as they are ASCII). 2009/8/20 marius d. marius.dan...@gmail.com Well the way I see it is lift:insert at= .. So the semantic would always be insert-at .. such as insert this markup at this bind position... which in essence is an insert operation that makes a lot of sense - to me at least. On the other hand lift:embed embeds a template into *this* position so there is no *at* semantic. So the way I see it the two don't step on each other toes. Br's, Marius On Aug 20, 4:34 pm, Timothy Perrett timo...@getintheloop.eu wrote: Can I just make an objection to calling it insert - IMO, that's a conflict with the language semantic of embed - I agree with-param is not ideal, but im not sure that insert is ideal either. I also agree with marius, what would you suggest to resolve this issue? I tried to post yesterday but it looks like my mail didn't make it into the group. Cheers, Tim On 20/08/2009 14:15, marius d. marius.dan...@gmail.com wrote: I will add lift:insert support .. personally I don't feel very comfortable allowing builtin snippets to have different names. One case I'm thinking of that people may change them, post issues on the list and we'd have o idea what the user really uses which may lead to longer discussions and support. I've learned my lesson with over- customization of things; it can bring real pains sometimes. Just my 2 cents ... Br's, Marius On Aug 20, 4:09 pm, inca incarn...@whiteants.net wrote: Yes, David, that's wonderful idea, too. Should eliminate many headaches. On 20 авг, 01:59, David Pollak feeder.of.the.be...@gmail.com wrote: On Wed, Aug 19, 2009 at 2:46 AM, marius d. marius.dan...@gmail.com wrote: This is a decision that needs consensus ... and David's agreement. I'm cool with it. It might also be worth thinking about creating some alias library so folks could change the default names of Lift's snippets. Or maybe that's just a bad idea. Personally I agree with it but others may not. Br's, Marius On Aug 19, 12:41 pm, inca incarn...@whiteants.net wrote: Why not just introduce the new tag, leaving the former alone (possibly deprecated in next major releases)? On 19 авг, 12:07, marius d. marius.dan...@gmail.com wrote: Yes we tried to deprecate it but later on we un-derprecate it :) So you can use lift:with-param safely. Purely for naming perspective lift:insert seems to me more intuitive than lift:with-param ... I'm not sure if this is a strong enough motivation to change the name hence inducing a breaking change. Br's, Marius On Aug 19, 10:55 am, inca incarn...@whiteants.net wrote: As suggested inhttp:// groups.google.com/group/liftweb/browse_thread/thread/d664b712d... by Mr. Marius D., I should use lift:with-param in order to insert content into multiple bind points of template. But recently I read that this tag is deprecated. What alternatives are available? P.S. I would propose lift:insert at=bindPointName tag for this purpose. And the contents of lift:bind name=bindPointName tag should be assumed as default if none lift:insert ... tag overrides it. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] Re: lift:with-params deprecation alternatives
Marius, you make a fair point. In that case, im down with insert at='sdf'. I am right to think this will directly *replace* with-param? Cheers, Tim On 20/08/2009 14:53, marius d. marius.dan...@gmail.com wrote: Well the way I see it is lift:insert at= .. So the semantic would always be insert-at .. such as insert this markup at this bind position... which in essence is an insert operation that makes a lot of sense - to me at least. On the other hand lift:embed embeds a template into *this* position so there is no *at* semantic. So the way I see it the two don't step on each other toes. Br's, Marius On Aug 20, 4:34 pm, Timothy Perrett timo...@getintheloop.eu wrote: Can I just make an objection to calling it insert - IMO, that's a conflict with the language semantic of embed - I agree with-param is not ideal, but im not sure that insert is ideal either. I also agree with marius, what would you suggest to resolve this issue? I tried to post yesterday but it looks like my mail didn't make it into the group. Cheers, Tim On 20/08/2009 14:15, marius d. marius.dan...@gmail.com wrote: I will add lift:insert support .. personally I don't feel very comfortable allowing builtin snippets to have different names. One case I'm thinking of that people may change them, post issues on the list and we'd have o idea what the user really uses which may lead to longer discussions and support. I've learned my lesson with over- customization of things; it can bring real pains sometimes. Just my 2 cents ... Br's, Marius On Aug 20, 4:09 pm, inca incarn...@whiteants.net wrote: Yes, David, that's wonderful idea, too. Should eliminate many headaches. On 20 авг, 01:59, David Pollak feeder.of.the.be...@gmail.com wrote: On Wed, Aug 19, 2009 at 2:46 AM, marius d. marius.dan...@gmail.com wrote: This is a decision that needs consensus ... and David's agreement. I'm cool with it. It might also be worth thinking about creating some alias library so folks could change the default names of Lift's snippets. Or maybe that's just a bad idea. Personally I agree with it but others may not. Br's, Marius On Aug 19, 12:41 pm, inca incarn...@whiteants.net wrote: Why not just introduce the new tag, leaving the former alone (possibly deprecated in next major releases)? On 19 авг, 12:07, marius d. marius.dan...@gmail.com wrote: Yes we tried to deprecate it but later on we un-derprecate it :) So you can use lift:with-param safely. Purely for naming perspective lift:insert seems to me more intuitive than lift:with-param ... I'm not sure if this is a strong enough motivation to change the name hence inducing a breaking change. Br's, Marius On Aug 19, 10:55 am, inca incarn...@whiteants.net wrote: As suggested inhttp:// groups.google.com/group/liftweb/browse_thread/thread/d664b712d... by Mr. Marius D., I should use lift:with-param in order to insert content into multiple bind points of template. But recently I read that this tag is deprecated. What alternatives are available? P.S. I would propose lift:insert at=bindPointName tag for this purpose. And the contents of lift:bind name=bindPointName tag should be assumed as default if none lift:insert ... tag overrides it. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] Re: lift:with-params deprecation alternatives
I love lift:bind-to name= or lift:bind-at name= ... Br's, Marius On Aug 20, 5:43 pm, David Pollak feeder.of.the.be...@gmail.com wrote: How about lift:bind-to name=.../ which works with lift:bind .../ I'm also open to non-English words that mean the same (as long as they are ASCII). 2009/8/20 marius d. marius.dan...@gmail.com Well the way I see it is lift:insert at= .. So the semantic would always be insert-at .. such as insert this markup at this bind position... which in essence is an insert operation that makes a lot of sense - to me at least. On the other hand lift:embed embeds a template into *this* position so there is no *at* semantic. So the way I see it the two don't step on each other toes. Br's, Marius On Aug 20, 4:34 pm, Timothy Perrett timo...@getintheloop.eu wrote: Can I just make an objection to calling it insert - IMO, that's a conflict with the language semantic of embed - I agree with-param is not ideal, but im not sure that insert is ideal either. I also agree with marius, what would you suggest to resolve this issue? I tried to post yesterday but it looks like my mail didn't make it into the group. Cheers, Tim On 20/08/2009 14:15, marius d. marius.dan...@gmail.com wrote: I will add lift:insert support .. personally I don't feel very comfortable allowing builtin snippets to have different names. One case I'm thinking of that people may change them, post issues on the list and we'd have o idea what the user really uses which may lead to longer discussions and support. I've learned my lesson with over- customization of things; it can bring real pains sometimes. Just my 2 cents ... Br's, Marius On Aug 20, 4:09 pm, inca incarn...@whiteants.net wrote: Yes, David, that's wonderful idea, too. Should eliminate many headaches. On 20 авг, 01:59, David Pollak feeder.of.the.be...@gmail.com wrote: On Wed, Aug 19, 2009 at 2:46 AM, marius d. marius.dan...@gmail.com wrote: This is a decision that needs consensus ... and David's agreement. I'm cool with it. It might also be worth thinking about creating some alias library so folks could change the default names of Lift's snippets. Or maybe that's just a bad idea. Personally I agree with it but others may not. Br's, Marius On Aug 19, 12:41 pm, inca incarn...@whiteants.net wrote: Why not just introduce the new tag, leaving the former alone (possibly deprecated in next major releases)? On 19 авг, 12:07, marius d. marius.dan...@gmail.com wrote: Yes we tried to deprecate it but later on we un-derprecate it :) So you can use lift:with-param safely. Purely for naming perspective lift:insert seems to me more intuitive than lift:with-param ... I'm not sure if this is a strong enough motivation to change the name hence inducing a breaking change. Br's, Marius On Aug 19, 10:55 am, inca incarn...@whiteants.net wrote: As suggested inhttp:// groups.google.com/group/liftweb/browse_thread/thread/d664b712d... by Mr. Marius D., I should use lift:with-param in order to insert content into multiple bind points of template. But recently I read that this tag is deprecated. What alternatives are available? P.S. I would propose lift:insert at=bindPointName tag for this purpose. And the contents of lift:bind name=bindPointName tag should be assumed as default if none lift:insert ... tag overrides it. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] Re: lift:with-params deprecation alternatives
Personally I think that as a replacement for the at attribute when there are a few binds, it would be more consistent to name the element at too, and think of something else for the attribute: Something like lift:at name=sidebar. - marius d.marius.dan...@gmail.com wrote: Well the way I see it is lift:insert at= .. So the semantic would always be insert-at .. such as insert this markup at this bind position... which in essence is an insert operation that makes a lot of sense - to me at least. On the other hand lift:embed embeds a template into *this* position so there is no *at* semantic. So the way I see it the two don't step on each other toes. Br's, Marius On Aug 20, 4:34 pm, Timothy Perrett timo...@getintheloop.eu wrote: Can I just make an objection to calling it insert - IMO, that's a conflict with the language semantic of embed - I agree with-param is not ideal, but im not sure that insert is ideal either. I also agree with marius, what would you suggest to resolve this issue? I tried to post yesterday but it looks like my mail didn't make it into the group. Cheers, Tim On 20/08/2009 14:15, marius d. marius.dan...@gmail.com wrote: I will add lift:insert support .. personally I don't feel very comfortable allowing builtin snippets to have different names. One case I'm thinking of that people may change them, post issues on the list and we'd have o idea what the user really uses which may lead to longer discussions and support. I've learned my lesson with over- customization of things; it can bring real pains sometimes. Just my 2 cents ... Br's, Marius On Aug 20, 4:09 pm, inca incarn...@whiteants.net wrote: Yes, David, that's wonderful idea, too. Should eliminate many headaches. On 20 авг, 01:59, David Pollak feeder.of.the.be...@gmail.com wrote: On Wed, Aug 19, 2009 at 2:46 AM, marius d. marius.dan...@gmail.com wrote: This is a decision that needs consensus ... and David's agreement. I'm cool with it. It might also be worth thinking about creating some alias library so folks could change the default names of Lift's snippets. Or maybe that's just a bad idea. Personally I agree with it but others may not. Br's, Marius On Aug 19, 12:41 pm, inca incarn...@whiteants.net wrote: Why not just introduce the new tag, leaving the former alone (possibly deprecated in next major releases)? On 19 авг, 12:07, marius d. marius.dan...@gmail.com wrote: Yes we tried to deprecate it but later on we un-derprecate it :) So you can use lift:with-param safely. Purely for naming perspective lift:insert seems to me more intuitive than lift:with-param ... I'm not sure if this is a strong enough motivation to change the name hence inducing a breaking change. Br's, Marius On Aug 19, 10:55 am, inca incarn...@whiteants.net wrote: As suggested inhttp:// groups.google.com/group/liftweb/browse_thread/thread/d664b712d... by Mr. Marius D., I should use lift:with-param in order to insert content into multiple bind points of template. But recently I read that this tag is deprecated. What alternatives are available? P.S. I would propose lift:insert at=bindPointName tag for this purpose. And the contents of lift:bind name=bindPointName tag should be assumed as default if none lift:insert ... tag overrides it. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] Re: lift:with-params deprecation alternatives
Ok .. I committed lift:bind-at name=/. Personally I like it better then insert because it contains a good hint by its very name that it is related with lift:bind. Of course if you hate it it can be easily changed :) ... but IMHO it doesn't worth having large discussions on such things. Br's, Marius On Aug 20, 7:17 pm, marius d. marius.dan...@gmail.com wrote: I love lift:bind-to name= or lift:bind-at name= ... Br's, Marius On Aug 20, 5:43 pm, David Pollak feeder.of.the.be...@gmail.com wrote: How about lift:bind-to name=.../ which works with lift:bind .../ I'm also open to non-English words that mean the same (as long as they are ASCII). 2009/8/20 marius d. marius.dan...@gmail.com Well the way I see it is lift:insert at= .. So the semantic would always be insert-at .. such as insert this markup at this bind position... which in essence is an insert operation that makes a lot of sense - to me at least. On the other hand lift:embed embeds a template into *this* position so there is no *at* semantic. So the way I see it the two don't step on each other toes. Br's, Marius On Aug 20, 4:34 pm, Timothy Perrett timo...@getintheloop.eu wrote: Can I just make an objection to calling it insert - IMO, that's a conflict with the language semantic of embed - I agree with-param is not ideal, but im not sure that insert is ideal either. I also agree with marius, what would you suggest to resolve this issue? I tried to post yesterday but it looks like my mail didn't make it into the group. Cheers, Tim On 20/08/2009 14:15, marius d. marius.dan...@gmail.com wrote: I will add lift:insert support .. personally I don't feel very comfortable allowing builtin snippets to have different names. One case I'm thinking of that people may change them, post issues on the list and we'd have o idea what the user really uses which may lead to longer discussions and support. I've learned my lesson with over- customization of things; it can bring real pains sometimes. Just my 2 cents ... Br's, Marius On Aug 20, 4:09 pm, inca incarn...@whiteants.net wrote: Yes, David, that's wonderful idea, too. Should eliminate many headaches. On 20 авг, 01:59, David Pollak feeder.of.the.be...@gmail.com wrote: On Wed, Aug 19, 2009 at 2:46 AM, marius d. marius.dan...@gmail.com wrote: This is a decision that needs consensus ... and David's agreement. I'm cool with it. It might also be worth thinking about creating some alias library so folks could change the default names of Lift's snippets. Or maybe that's just a bad idea. Personally I agree with it but others may not. Br's, Marius On Aug 19, 12:41 pm, inca incarn...@whiteants.net wrote: Why not just introduce the new tag, leaving the former alone (possibly deprecated in next major releases)? On 19 авг, 12:07, marius d. marius.dan...@gmail.com wrote: Yes we tried to deprecate it but later on we un-derprecate it :) So you can use lift:with-param safely. Purely for naming perspective lift:insert seems to me more intuitive than lift:with-param ... I'm not sure if this is a strong enough motivation to change the name hence inducing a breaking change. Br's, Marius On Aug 19, 10:55 am, inca incarn...@whiteants.net wrote: As suggested inhttp:// groups.google.com/group/liftweb/browse_thread/thread/d664b712d... by Mr. Marius D., I should use lift:with-param in order to insert content into multiple bind points of template. But recently I read that this tag is deprecated. What alternatives are available? P.S. I would propose lift:insert at=bindPointName tag for this purpose. And the contents of lift:bind name=bindPointName tag should be assumed as default if none lift:insert ... tag overrides it. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] Re: lift:with-params deprecation alternatives
The neat thing about the insert is that it is consistent with other
templating frameworks (Tiles [http://struts.apache.org/1.x/struts-
tiles/tlddoc/tiles/insert.html], Facelets [http://www.roseindia.net/
jsf/insert.shtml], etc.), so it would be easy for folks like me to
migrate to Lift. I don't think that lift:bind-at is a good
replacement: it looks very similar to lift:bind when browsing the
code (I've just tested this, not very eye-catching difference).
And if you really like minimal typing, call it lift:put at= (it is
one letter smaller than lift:at name=) :) And yes, it's naming
policy is still consistent with other tags (verbs as tag names and
pronouns as attributes).
About the built-in snippet aliases... I don't see anything wrong
there. Just let them have custom xml prefixes, and it would be
perfectly clear that it is an alias. I, personally, think that xml
prefixes are great. Say I have a snippet like this:
class HtmlUI {
def wrapper(in:NodeSeq):NodeSeq =
div class=w
div class=e
div class=c{in}
/div
/div
/div
def button(in:NodeSeq):NodeSeq =
a class=button
style={background:transparent url('/img/buttons/bkg- + S.attr
(bkg).openOr(green) + .png') no-repeat}
title={S.attr(title).openOr()}
href={S.attr(href).openOr(#)}
img src={/img/buttons/ + S.attr(icon).openOr() + .png}
alt=/
div class=gloss/
/a
...etc...
}
So every time I need a wrapper or a glossy button I would write
lift:HtmlUI.wrapper ... or lift:HtmlUI.button
Now if I had a chance to create xhtml prefix alias for this snippet
(something like that:
LiftRules.addSnippetMapping(ui - HtmlUI)
), than my xhtml templates would reduce a lot (ui:wrapper ... and
ui:button ...) along with increased readability.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@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] Re: lift:with-params deprecation alternatives
Its actually not deprecated! We did deprecate it for a while, then straight away un-deprecated it because people wanted it. So you can use it without any problems or concerns... Cheers, Tim On 19/08/2009 08:55, inca incarn...@whiteants.net wrote: As suggested in http://groups.google.com/group/liftweb/browse_thread/thread/d664b712d08fbf41 by Mr. Marius D., I should use lift:with-param in order to insert content into multiple bind points of template. But recently I read that this tag is deprecated. What alternatives are available? P.S. I would propose lift:insert at=bindPointName tag for this purpose. And the contents of lift:bind name=bindPointName tag should be assumed as default if none lift:insert ... tag overrides it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] Re: lift:with-params deprecation alternatives
Yes we tried to deprecate it but later on we un-derprecate it :) So you can use lift:with-param safely. Purely for naming perspective lift:insert seems to me more intuitive than lift:with-param ... I'm not sure if this is a strong enough motivation to change the name hence inducing a breaking change. Br's, Marius On Aug 19, 10:55 am, inca incarn...@whiteants.net wrote: As suggested inhttp://groups.google.com/group/liftweb/browse_thread/thread/d664b712d... by Mr. Marius D., I should use lift:with-param in order to insert content into multiple bind points of template. But recently I read that this tag is deprecated. What alternatives are available? P.S. I would propose lift:insert at=bindPointName tag for this purpose. And the contents of lift:bind name=bindPointName tag should be assumed as default if none lift:insert ... tag overrides it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] Re: lift:with-params deprecation alternatives
This is a decision that needs consensus ... and David's agreement. Personally I agree with it but others may not. Br's, Marius On Aug 19, 12:41 pm, inca incarn...@whiteants.net wrote: Why not just introduce the new tag, leaving the former alone (possibly deprecated in next major releases)? On 19 авг, 12:07, marius d. marius.dan...@gmail.com wrote: Yes we tried to deprecate it but later on we un-derprecate it :) So you can use lift:with-param safely. Purely for naming perspective lift:insert seems to me more intuitive than lift:with-param ... I'm not sure if this is a strong enough motivation to change the name hence inducing a breaking change. Br's, Marius On Aug 19, 10:55 am, inca incarn...@whiteants.net wrote: As suggested inhttp://groups.google.com/group/liftweb/browse_thread/thread/d664b712d... by Mr. Marius D., I should use lift:with-param in order to insert content into multiple bind points of template. But recently I read that this tag is deprecated. What alternatives are available? P.S. I would propose lift:insert at=bindPointName tag for this purpose. And the contents of lift:bind name=bindPointName tag should be assumed as default if none lift:insert ... tag overrides it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] Re: lift:with-params deprecation alternatives
Why not just introduce the new tag, leaving the former alone (possibly deprecated in next major releases)? On 19 авг, 12:07, marius d. marius.dan...@gmail.com wrote: Yes we tried to deprecate it but later on we un-derprecate it :) So you can use lift:with-param safely. Purely for naming perspective lift:insert seems to me more intuitive than lift:with-param ... I'm not sure if this is a strong enough motivation to change the name hence inducing a breaking change. Br's, Marius On Aug 19, 10:55 am, inca incarn...@whiteants.net wrote: As suggested inhttp://groups.google.com/group/liftweb/browse_thread/thread/d664b712d... by Mr. Marius D., I should use lift:with-param in order to insert content into multiple bind points of template. But recently I read that this tag is deprecated. What alternatives are available? P.S. I would propose lift:insert at=bindPointName tag for this purpose. And the contents of lift:bind name=bindPointName tag should be assumed as default if none lift:insert ... tag overrides it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] Re: lift:with-params deprecation alternatives
Okay, thanks a lot! Let's hope the others will accept a proposal... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] Re: lift:with-params deprecation alternatives
I'm not sure if my consensus matters or not, but I like lift:insert better than lift:with-param. -Ross On Aug 19, 2009, at 9:10 AM, inca wrote: Okay, thanks a lot! Let's hope the others will accept a proposal... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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] Re: lift:with-params deprecation alternatives
On Wed, Aug 19, 2009 at 2:46 AM, marius d. marius.dan...@gmail.com wrote: This is a decision that needs consensus ... and David's agreement. I'm cool with it. It might also be worth thinking about creating some alias library so folks could change the default names of Lift's snippets. Or maybe that's just a bad idea. Personally I agree with it but others may not. Br's, Marius On Aug 19, 12:41 pm, inca incarn...@whiteants.net wrote: Why not just introduce the new tag, leaving the former alone (possibly deprecated in next major releases)? On 19 авг, 12:07, marius d. marius.dan...@gmail.com wrote: Yes we tried to deprecate it but later on we un-derprecate it :) So you can use lift:with-param safely. Purely for naming perspective lift:insert seems to me more intuitive than lift:with-param ... I'm not sure if this is a strong enough motivation to change the name hence inducing a breaking change. Br's, Marius On Aug 19, 10:55 am, inca incarn...@whiteants.net wrote: As suggested inhttp:// groups.google.com/group/liftweb/browse_thread/thread/d664b712d... by Mr. Marius D., I should use lift:with-param in order to insert content into multiple bind points of template. But recently I read that this tag is deprecated. What alternatives are available? P.S. I would propose lift:insert at=bindPointName tag for this purpose. And the contents of lift:bind name=bindPointName tag should be assumed as default if none lift:insert ... tag overrides it. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@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 -~--~~~~--~~--~--~---
