A quick just before going to bed reaction is that your change would
solve the issue.
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...
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 <[email protected]> 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
