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
-~----------~----~----~----~------~----~------~--~---

Reply via email to