Is that now part of the Lift library, or is that hand-coded? On Thu, Oct 15, 2009 at 12:59 PM, Timothy Perrett <timo...@getintheloop.eu>wrote:
> Im using -%> in production code and personally i think it looks fine! > Cheers, Tim > > On 15 Oct 2009, at 19:12, Derek Chen-Becker wrote: > > Did this discussion ever lead to anything concrete? I just had to update > part of the book that talks about this and I added a note to follow-up in > case we need to document a change in 1.1. In particular, if people have 1.1 > code that uses the current (according to David, broken) functionality, it's > going to be a big surprise if the attributes suddenly disappear between > releases. Can we at least do a deprecation and log a warning if we want to > change the behavior? > > Derek > > On Mon, Aug 17, 2009 at 2:16 PM, Naftoli Gugenheim > <naftoli...@gmail.com>wrote: > >> What's the advantage of ->>? That it looks more like an arrow?Personally >> I'm fine either way, but I think the important question is what most people >> find conveys the intent. I wish I would get more responses to the question! >> :) One the one hand ->> goes hand in hand with -> for regular binds, while >> %> doesn't look like an arrow but it does say "attribute" in it! Maybe %-> ? >> ->% ? %%> ? >> >> Not sure what happened to the formatting! How do I make sure it stays? >> (I'm using GMail now.) >> Here's a screenshot :) >> <tmp.jpg> >> >> >> On Mon, Aug 17, 2009 at 4:07 PM, marius d. <marius.dan...@gmail.com>wrote: >> >>> >>> One small advice ... your code would probably be be read by more >>> people if some minimal formatting is applied :) ... I can imagine you >>> didn't do it on purpose though :) >>> >>> Actually I like it. >>> >>> Just something really unimportant and subjective: how do you feel >>> about ->> instead of %> ? (I understood your rationale of choosing %) >>> >>> Br's, >>> Marius >>> >>> On Aug 17, 10:02 pm, Naftoli Gugenheim <naftoli...@gmail.com> wrote: >>> > Hi, sorry, not sure why I didn't see your message earlier. Strange... >>> Has >>> > anyone written any code to address this topic in the meantime? In case >>> not, >>> > here's all the code I've written for such purposes; tell me what you >>> think. >>> > >>> > def keepAttrs(elem: Elem) = (ns: NodeSeq) => BindHelpers.currentNode >>> match { >>> > case Full(inElem) => elem % inElem.attributes case other => elem } >>> protected >>> > class Keepable(elem: Elem) { def %% = keepAttrs(elem) } implicit def >>> > elemToKeepable(elem: Elem): Keepable = new Keepable(elem) protected >>> class >>> > KeepBind(name: String) { val emptyFn: NodeSeq=>NodeSeq = _ => >>> NodeSeq.Empty >>> > import scala.xml.{Node, Text} import net.liftweb.util.Bindable def >>> %>(in: >>> > Elem) = FuncBindParam(name, keepAttrs(in)) def %>(in: Box[Elem]) = >>> > FuncBindParam(name, in.map(keepAttrs) openOr emptyFn) def %>(in: >>> > Option[Elem]) = FuncBindParam(name, in.map(keepAttrs) getOrElse >>> emptyFn) } >>> > implicit def strToKeepAssoc(name: String): KeepBind = new >>> KeepBind(name) >>> > >>> > keepAttrs could actually be implemented shorter: >>> > >>> > elem currentNode.map(_.attributes).openOr(scala.xml.Null)) >>> > >>> > etc. >>> > >>> > On Fri, Aug 14, 2009 at 4:50 PM, marius d. <marius.dan...@gmail.com> >>> wrote: >>> > >>> > > IMHO: >>> > >>> > > The problem with >>> > >>> > > "name" some_new_operator_beside_-> expr >>> > >>> > > would lead to a handful of overloading as -> in SuperArrowAssoc. >>> Looks >>> > > a little messy to me. >>> > >>> > > Looks like we already have a way to do this: >>> > >>> > > import Helpers._ >>> > >>> > > "name" -> {node: NodeSeq => mixinAttributes(expr >>> _that_yields_an_Elem) >>> > > (node)} >>> > >>> > > Would that be too ... boilerplate for you? >>> > >>> > > Br's, >>> > > Marius >>> > >>> > > On Aug 14, 11:18 pm, Naftoli Gugenheim <naftoli...@gmail.com> wrote: >>> > > > As I mentioned, I wrote some code that allows you to use %> instead >>> of -> >>> > > to preserve the attributes. (I chose it because the % symbol is used >>> to >>> > > merge attributes to an Elem.) The right side can be an Elem or a >>> Box/Option >>> > > of an Elem. >>> > > > What do people think of this syntax? >>> > > > P.S. Another way is to append ".%%" to an Elem making it into a >>> NodeSeq >>> > > function. >>> > >>> > > > ------------------------------------- >>> > >>> > > > marius d.<marius.dan...@gmail.com> wrote: >>> > >>> > > > The book exposes current functionality for Lift 1.0. If >>> functionality >>> > > > X was not intended to be there is a different story, but regardless >>> it >>> > > > is there and the way I see it it is OK to be in the book. >>> > >>> > > > Personally I don't see it as defect as preserving attributes (to >>> the >>> > > > top level resulting NodeSeq) may be quite handy in certain >>> situations >>> > > > even that contradicts David's design intent. But this is just a >>> > > > personal opinion. After David removes this, a helper to copy >>> > > > attributes is needed IMO. So Naftoli if you want to do this please >>> go >>> > > > ahead ... or if you don't want it I'll do it. >>> > >>> > > > Br's, >>> > > > Marius >>> > >>> > > > On Aug 14, 7:43 pm, Naftoli Gugenheim <naftoli...@gmail.com> >>> wrote: >>> > >>> > > > > The book seems to think it's intentional! >>> > > > > But why can't unprefixed nodes by preserved automatically? Maybe >>> there >>> > > could be a setting? >>> > > > > Thanks. >>> > >>> > > > > ------------------------------------- >>> > >>> > > > > David Pollak<feeder.of.the.be...@gmail.com> wrote: >>> > >>> > > > > On Fri, Aug 14, 2009 at 9:23 AM, Naftoli Gugenheim < >>> > > naftoli...@gmail.com>wrote: >>> > >>> > > > > > Exactly! >>> > >>> > > > > > ------------------------------------- >>> > > > > > Derek Chen-Becker<dchenbec...@gmail.com> wrote: >>> > >>> > > > > > Basically, you're asking why a bind tag like >>> > >>> > > > > > <ledger:entry id="foo" class="bar" /> >>> > >>> > > > > > doesn't preserve the id and class attrs when it binds, but >>> > >>> > > > > > <ledger:entry ledger:id="foo" ledger:class="bar" /> >>> > >>> > > > > > does? >>> > >>> > > > > If bind("ledger", <ledger:entry ledger:id="foo" >>> ledger:class="bar" />, >>> > > > > "entry" -> <foo/>) >>> > > > > results in anything other than <foo/> it's a defect. >>> > >>> > > > > Wow... looks like it does... it's a defect and I'll fix it. >>> > >>> > > > > > Derek >>> > >>> > > > > > On Fri, Aug 14, 2009 at 10:08 AM, Naftoli Gugenheim < >>> > > naftoli...@gmail.com >>> > > > > > >wrote: >>> > >>> > > > > > > Of course you can access it from the snippet. But if you want >>> it to >>> > > be >>> > > > > > > output automatically, then you prefix it with whatever the >>> node's >>> > > prefix >>> > > > > > is. >>> > > > > > > In other words, by default it's not outputted. >>> > >>> > > > > > > ------------------------------------- >>> > > > > > > David Pollak<feeder.of.the.be...@gmail.com> wrote: >>> > >>> > > > > > > On Thu, Aug 13, 2009 at 9:06 PM, Naftoli Gugenheim < >>> > > naftoli...@gmail.com >>> > > > > > > >wrote: >>> > >>> > > > > > > > What I would like to do: >>> > > > > > > > <label for="name">Name</label> <person:name I'd="name" >>> > > size="10" >>> > > > > > > > class="special" style="vertical-align: top" maxlength="5" >>> > > tabindex="1" >>> > > > > > /> >>> > > > > > > > Okay, just a little contrived... >>> > > > > > > > My understanding is you can do this by prefixing the >>> attribute >>> > > with >>> > > > > > > > "lift:"; otherwise it will not be output but is available >>> to the >>> > > > > > snippet >>> > > > > > > > code, i.e., without the prefix you are making an attribute >>> > > available to >>> > > > > > > the >>> > > > > > > > snippet but that's it. >>> > >>> > > > > > > I'm sorry, but I'm still clueless about what you're talking >>> about. >>> > >>> > > > > > > Do you want to bind to <person:name/> and add the attributes >>> in the >>> > > > > > > <person:name /> element to the resulting element? >>> > >>> > > > > > > The lift prefix has nothing to do with binding. Binding is >>> done in >>> > > > > > > net.liftweb.util and is purely a way of substituting dynamic >>> XML >>> > > into >>> > > > > > well >>> > > > > > > defined points in a NodeSeq. >>> > >>> > > > > > > So... if you want to include the attributes of an Elem that >>> you are >>> > > > > > > replacing during a bind operation, you have access to the >>> current >>> > > node >>> > > > > > via >>> > > > > > > Helpers.currentNode: Box[Elem] and you can get the >>> attributes: >>> > > > > > > currentNode.map(_.attributes) openOr Null >>> > >>> > > > > > > > I'm getting this from Exploring Lift page 115. >>> > >>> > > > > > > > ------------------------------------- >>> > > > > > > > David Pollak<feeder.of.the.be...@gmail.com> wrote: >>> > >>> > > > > > > > On Thu, Aug 13, 2009 at 7:24 PM, Naftoli Gugenheim < >>> > > > > > naftoli...@gmail.com >>> > > > > > > > >wrote: >>> > >>> > > > > > > > > Why was the decision made, if I understand correctly, >>> that >>> > > normal >>> > > > > > > > > attributes are not preserved in a bound node, and are are >>> only >>> > > > > > > available >>> > > > > > > > for >>> > > > > > > > > the snippet's usage, and if you want the attribute to be >>> > > "sticky" you >>> > > > > > > > have >>> > > > > > > > > to prefix it with "lift:"? Wouldn't it be better the >>> other way? >>> > >>> > > > > > > > I don't understand your question. Are you talking about >>> > > Helpers.bind() >>> > > > > > > or >>> > > > > > > > are you talking about snippet dispatching? >>> > >>> > > > > > > > Can you please provide an example of what happens now and >>> what >>> > > you >>> > > > > > would >>> > > > > > > > expect to happen? >>> > >>> > > > > > > > > One of lift's design goals is to help keep the static >>> html in >>> > > the >>> > > > > > view >>> > > > > > > > and >>> > > > > > > > > the logic in the code, and to provide a templating system >>> that >>> > > > > > doesn't >>> > > > > > > > > interfere with visual web designers. It seems to me that >>> it >>> > > would >>> > > > > > > further >>> > > > > > > > > this goal if html attributes could be properly specified >>> in the >>> > > view >>> > > > > > > > html. >>> > >>> > > > > > > > -- >>> > > > > > > > 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 >>> > >>> > > > > -- >>> > > > > 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 -~----------~----~----~----~------~----~------~--~---