I guess #2 was what I was looking for. :)
I wrote some code that enables me to bind
"query" %> SHtml.text(clientQuery, clientQuery=_)
which means you're actually binding to a function that preserves the input
node's attributes.
Does anyone like/dislike the syntax or feature?
Thanks.
-------------------------------------
David Pollak<feeder.of.the.be...@gmail.com> wrote:
On Fri, Aug 14, 2009 at 9:55 AM, Naftoli Gugenheim <naftoli...@gmail.com>wrote:
>
> Where above?
The contents of my messages send 35 minutes ago:
This has nothing to do with snippets. This is below the level of the
snippet. This is the operation of the bind() operation (if I understand
your question correctly.)
With a bind, you are replacing one Elem with a NodeSeq. There are plenty of
helpers that allow you to do this.
If you want to do something that's not provided by the helper, you can write
a function and wrap it in a FuncBindParam to do things the way you want.
Nothing in Lift is stopping that from happening.
How, why is did I make the choice to do a pure substitution rather than
doing something fancier by default:
1. You get what you bind rather than having some attributes magically
added.
2. There's no requirement that you bind an Elem to an Elem... thus if you
bind a NodeSeq, what's the correct behavior (adding attrs to every Elem,
every top-level Elem, the first Elem)?
3. If there is magic, no matter what the rules are, someone will be
confused (look through the archives relating to the newbie issue of not
explicitly setting the return type of snippets to NodeSeq)
So, I believe the default behavior is the correct behavior.
If you want to add a helper that will copy attrs from the bound Elem to a
newly provided Elem (not anything other than an Elem because of #2 above),
you're a committer... you can add it.
> Do mean when you said that binding is about inserting xml in well defined
> points?
> If so, I understand that, but it would be convenient if there was a simple
> way that SHtml inputs could take their attributes from the view.
As I said:
*If you want to add a helper that will copy attrs from the bound Elem to a
newly provided Elem (not anything other than an Elem because of #2 above),
you're a committer... you can add it.*
But more broadly (and this applies to everyone on the list), it's much
better to speak in code rather than English.
So, had you asked:
bind("ledger", <ledger:entry ledger:id="foo" ledger:class="bar" />, "entry"
-> <foo/>)
returns <foo id="foo" class="bar" />
but:
bind("ledger", <ledger:entry id="foo" class="bar" />, "entry" -> <foo/>)
returns <foo/>
Shouldn't it be the other way around?
You would have expressed the same question, but I wouldn't have asked 3
times what you were talking about. You would have framed the question in a
way I (and other folks on the list) could have understood it.
Whether it's posting a ticket or asking a question, put together as much
code as possible will help everyone understand what's going on, get on the
same page, and get to a good answer.
Thanks,
David
>
> -------------------------------------
> David Pollak<feeder.of.the.be...@gmail.com> wrote:
>
> On Fri, Aug 14, 2009 at 9:43 AM, Naftoli Gugenheim <naftoli...@gmail.com
> >wrote:
>
> >
> > The book seems to think it's intentional!
>
>
> I'm not sure how the code crept in, but it's wrong and should not have been
> part of Lift.
>
>
> >
> > But why can't unprefixed nodes by preserved automatically?
>
>
> I explained this above.
>
>
> > Maybe there could be a setting?
>
>
> I explained this above as well.
>
>
> >
> > 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 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
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > 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
> > > >
> > > >
> > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > >
> > >
> >
> >
> > --
> > 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
> >
> >
> >
> > >
> >
>
>
> --
> 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
>
>
>
> >
>
--
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
-~----------~----~----~----~------~----~------~--~---
