(you can tel I'm sleeping well :/ - too hot) The toList function is one of David's (todo example app). I do love the ability to curry :)
Marc On 06/01/2009, at 9:51 PM, Marius wrote: > > > > On Jan 6, 12:47 pm, Marc Boschma <[email protected]> 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 <[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 -~----------~----~----~----~------~----~------~--~---
