On Jan 6, 12:47 pm, Marc Boschma <marc+lift...@boschma.cx> wrote:
> A quick just before going to bed reaction is that your change would
> solve the issue.
Yeah it would ... (I mean it worked fine in my tests)
>
> It is interesting you focused on the "exclude" and not the
> "list" (which is what I have been playing with). I actually missed it
> was a similar case...
I just picked it randomly :) ... I've seen that you're using a
partially applied function doList ... (which I assume it is a curried
function):)
>
> Regards,
>
> Marc
>
> On 06/01/2009, at 9:24 PM, Marius wrote:
>
>
>
> > I just did a minor modification to the lift code so the actual node it
> > is passed to the BindParam and not its child. Now having:
>
> > bind("todo", html,
> > "exclude" -> {node:NodeSeq =>ajaxCheckbox
> > (QueryNotDone, v => {QueryNotDone(v); reDraw})}
> > ... )
>
> > and the markup <todo:exclude param="Dumb"/>
>
> > The node parameter to the anonymous function will be the
> > <todo:exclude> node and not its children. So now you can access the
> > "param" attribute from node. The change was in in_bind function so
> > instead of calling calcValue(s.child) I just call calcValue(s)
>
> > Looking at the existent BindParams this change does not seem to cause
> > side effects since the calcValue 'in' parameter is used only for
> > FuncXXXBindParam-s. The impact is that the user's function would now
> > get the actual node (from which now he can extract attributes) and not
> > the child nodes. But child nodes from the actual node are trivial to
> > obtain.
>
> > I did not commit this change as I'd like to see other opinions to see
> > if there is something that I missed somehow. If we get general
> > consensus of this change I can commit it right away and announce it as
> > a "breaking change".
>
> > Thoughts?
>
> > Br's,
> > Marius
>
> > On Jan 6, 12:02 pm, Marius <marius.dan...@gmail.com> wrote:
> >> A nice alternative would have been :
>
> >> bind("todo", html,
> >> "exclude" -> {node:NodeSeq =>ajaxCheckbox
> >> (QueryNotDone, v => {QueryNotDone(v); reDraw})}
> >> ... )
>
> >> But here the node impersonates the childNodes not the original node.
> >> So you still can not access the param attribute below
>
> >> <todo:exclude param="Dumb"/>
>
> >> but you can do it like:
>
> >> <todo:exclude ><meta param="dumb"/></todo:exclude>
>
> >> and you have full access to the meta node as it is a child of
> >> todo:exclude. Hence you can pass state.
>
> >> I know, it is not ideal but should be workable until snippet child-
> >> node attributes are exposed in one way or another.
>
> >> Br's,
> >> Marius
>
> >> Marc Boschma wrote:
> >>> I have been playing with the ToDo example application and having fun
> >>> in manipulating XML.
>
> >>> With the <todo:list/> node I thought it would be good if the XHTML
> >>> designer could pass in some guidance to the doList(...) method
> >>> used in
> >>> bind(..). ie. <todo:list singular="true">...</todo:list>
>
> >>> Looking over the bind code I noticed that the attributes are not
> >>> accessible without ending up changing the calcValue method's
> >>> signature. I did initially try to knock up a
>
> >>> case class FuncWithAttrBindParam(name: String, value: (NodeSeq,
> >>> MetaData) => NodeSeq) extends Tuple2(name, value) with BindParam
>
> >>> and a corresponding
>
> >>> case Some(ns : FuncWithAttrBindParam) =>
>
> >>> in in_bind(...), but it all looks like a huge kludge.
>
> >>> It strikes me as a little deficient to be able to utilise attributes
> >>> within the context of a snippet and yet not within a bind. I know
> >>> bind
> >>> is quite embedded in lift now, but I think that this difference
> >>> might
> >>> prove a little frustrating. I know one solution is to just create a
> >>> bind("todo", html,
> >>> "exclude" ->
> >>> ajaxCheckbox(QueryNotDone, v => {QueryNotDone(v); reDraw}),
> >>> "list" -> doList(reDraw, false) _,
> >>> "list_singular" -> doList(reDraw, true)
> >>> _)
>
> >>> But I think from the XHtml designer's perspective that is counter
> >>> intuitive...
>
> >>> Thoughts?
>
> >>> ------
>
> >>> It should be noted that this is different to the case class
> >>> FuncAttrBindParam(name: String, value: NodeSeq => NodeSeq, newAttr:
> >>> String) extends BindParam with BindWithAttr. Which interesting
> >>> enough
> >>> has no corresponding SuperArrowAssoc -> method match. Maybe
>
> >>> def ->(t: Tuple2[String, NodeSeq]) = AttrBindParam(name, t._2,
> >>> t._1)
> >>> def ->(t: Tuple2[String, NodeSeq => NodeSeq]) =
> >>> FuncAttrBindParam(name, t._2, t._1)
>
> >>> And maybe even...
>
> >>> def ->[T](t: Tuple2[String, T]) = FuncAttrBindParam(name, (name
> >>> ->
> >>> t._2).calcValue _, t._1)
>
> >>> or
>
> >>> def ->[T](t: Tuple2[String, T]) = FuncAttrBindParam(name, (t._1
> >>> ->
> >>> t._2).calcValue _, t._1)
>
> >>> I'm not sure which is better on the last two... Just a thought.
>
> >>> Marc
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
