[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)
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
-~--~~~~--~~--~--~---
[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)
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 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
-~--~~~~--~~--~--~---
[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)
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
[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)
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
-~--~~~~--~~--~--~---
[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)
I've just had a thought as to how to make it not a breaking change.
Leave your change calcValue(s.child) I just call calcValue(s)
change:
case class FuncBindParam(name: String, value: NodeSeq = NodeSeq)
extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in)
}
to:
case class FuncBindParam(name: String, value: NodeSeq = NodeSeq)
extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.child)
}
That should prevent old code breaking... which would be a good
thing(tm) given the amount of code that uses bind(...)
then create something like:
case class FuncMetaDataBindParam(name: String, value: (MetaData,
NodeSeq) = NodeSeq) extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.attributes,
in.child)
}
along with adding to class SuperArrowAssoc...
def -(in: (MetaData, NodeSeq) = NodeSeq) =
FuncMetaDataBindParam(name, in)
That would be fairly clean...
-
Maybe for those that actually want the full node add:
case class FuncBoxBindParam(name: String, value: Box(NodeSeq) =
NodeSeq) extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(Full(in))
}
and you could go nuts and:
case class FuncPrefixAndLabelBindParam(name: String, value:
(String, String, NodeSeq) = NodeSeq) extends Tuple2(name, value) with
BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.prefix, in.label,
in.child)
}
etc...
On 06/01/2009, at 10:51 PM, Marc Boschma wrote:
(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 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
[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)
On Jan 6, 2:50 pm, Marc Boschma marc+lift...@boschma.cx wrote:
I've just had a thought as to how to make it not a breaking change.
Leave your change calcValue(s.child) I just call calcValue(s)
change:
case class FuncBindParam(name: String, value: NodeSeq = NodeSeq)
extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in)
}
to:
case class FuncBindParam(name: String, value: NodeSeq = NodeSeq)
extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.child)
}
That should prevent old code breaking... which would be a good
thing(tm) given the amount of code that uses bind(...)
bind(..) is used a lot but I don't think that many people uses bind
with FuncBindParam though. And I don't think this would be a major
breaking change.
then create something like:
case class FuncMetaDataBindParam(name: String, value: (MetaData,
NodeSeq) = NodeSeq) extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.attributes,
in.child)
}
along with adding to class SuperArrowAssoc...
def -(in: (MetaData, NodeSeq) = NodeSeq) =
FuncMetaDataBindParam(name, in)
That would be fairly clean...
It would but personally I prefer the initial proposal of providing the
full node and not just its childs. With this we don't need to add any
more code.
-
Maybe for those that actually want the full node add:
case class FuncBoxBindParam(name: String, value: Box(NodeSeq) =
NodeSeq) extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(Full(in))
}
and you could go nuts and:
case class FuncPrefixAndLabelBindParam(name: String, value:
(String, String, NodeSeq) = NodeSeq) extends Tuple2(name, value) with
BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.prefix, in.label,
in.child)
}
etc...
Sorry man, I like the initial proposal better as with minimal changes
we achieve quite a lot and no need for new code. However this is just
my preference, maybe DPP and others would like your proposal best so
it will be materializes in git master. But I still vote for simplicity
even if this imply a breaking change but IMHO this is a very minor
breaking change (unless I'm missing something here).
On 06/01/2009, at 10:51 PM, Marc Boschma wrote:
(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 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
[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)
Folks,
I'm about to commit up a non-breaking solution.
In bind, you can call:
BindHelpers.bindNodes.value: List[NodeSeq]
BindHelpers.currentNode.value: Elem
bindNodes is a list of the nodes that were passed into bind with the more
current node at the head of the list. If you're doing hierarchical binding,
you can see all the nodes that were passed into bind this was.
currentNode is available to the BindParam and it contains the parent Elem to
the NodeSeq that was passed into your BindParam. You can inspect attributes
to your heart's content.
Give it an hour or two for these changes to make their way through Hudson.
Thanks,
David
On Tue, Jan 6, 2009 at 4:50 AM, Marc Boschma
marc+lift...@boschma.cxmarc%2blift...@boschma.cx
wrote:
I've just had a thought as to how to make it not a breaking change.
Leave your change calcValue(s.child) I just call calcValue(s)
change:
case class FuncBindParam(name: String, value: NodeSeq = NodeSeq)
extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in)
}
to:
case class FuncBindParam(name: String, value: NodeSeq = NodeSeq)
extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.child)
}
That should prevent old code breaking... which would be a good
thing(tm) given the amount of code that uses bind(...)
then create something like:
case class FuncMetaDataBindParam(name: String, value: (MetaData,
NodeSeq) = NodeSeq) extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.attributes,
in.child)
}
along with adding to class SuperArrowAssoc...
def -(in: (MetaData, NodeSeq) = NodeSeq) =
FuncMetaDataBindParam(name, in)
That would be fairly clean...
-
Maybe for those that actually want the full node add:
case class FuncBoxBindParam(name: String, value: Box(NodeSeq) =
NodeSeq) extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(Full(in))
}
and you could go nuts and:
case class FuncPrefixAndLabelBindParam(name: String, value:
(String, String, NodeSeq) = NodeSeq) extends Tuple2(name, value) with
BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.prefix, in.label,
in.child)
}
etc...
On 06/01/2009, at 10:51 PM, Marc Boschma wrote:
(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
marc+lift...@boschma.cxmarc%2blift...@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
[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)
Very cool Dave !
thx,
Marius
On Jan 6, 4:36 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Folks,
I'm about to commit up a non-breaking solution.
In bind, you can call:
BindHelpers.bindNodes.value: List[NodeSeq]
BindHelpers.currentNode.value: Elem
bindNodes is a list of the nodes that were passed into bind with the more
current node at the head of the list. If you're doing hierarchical binding,
you can see all the nodes that were passed into bind this was.
currentNode is available to the BindParam and it contains the parent Elem to
the NodeSeq that was passed into your BindParam. You can inspect attributes
to your heart's content.
Give it an hour or two for these changes to make their way through Hudson.
Thanks,
David
On Tue, Jan 6, 2009 at 4:50 AM, Marc Boschma
marc+lift...@boschma.cxmarc%2blift...@boschma.cx
wrote:
I've just had a thought as to how to make it not a breaking change.
Leave your change calcValue(s.child) I just call calcValue(s)
change:
case class FuncBindParam(name: String, value: NodeSeq = NodeSeq)
extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in)
}
to:
case class FuncBindParam(name: String, value: NodeSeq = NodeSeq)
extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.child)
}
That should prevent old code breaking... which would be a good
thing(tm) given the amount of code that uses bind(...)
then create something like:
case class FuncMetaDataBindParam(name: String, value: (MetaData,
NodeSeq) = NodeSeq) extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.attributes,
in.child)
}
along with adding to class SuperArrowAssoc...
def -(in: (MetaData, NodeSeq) = NodeSeq) =
FuncMetaDataBindParam(name, in)
That would be fairly clean...
-
Maybe for those that actually want the full node add:
case class FuncBoxBindParam(name: String, value: Box(NodeSeq) =
NodeSeq) extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(Full(in))
}
and you could go nuts and:
case class FuncPrefixAndLabelBindParam(name: String, value:
(String, String, NodeSeq) = NodeSeq) extends Tuple2(name, value) with
BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.prefix, in.label,
in.child)
}
etc...
On 06/01/2009, at 10:51 PM, Marc Boschma wrote:
(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
marc+lift...@boschma.cxmarc%2blift...@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/
[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)
On Jan 6, 7:15 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
I also added
BindHelpers.attr(tag): Option[NodeSeq]
so you can do something like:
span class={BindHelpers.attr(class).../span
and:
BindHelpers.attr(prefix, tag)
I think it is committed to curAttr which personally I'm not a fan ...
Doyou mind if I change it to attr or nodeAttr ?
Thanks,
David
On Tue, Jan 6, 2009 at 9:13 AM, Marius marius.dan...@gmail.com wrote:
Very cool Dave !
thx,
Marius
On Jan 6, 4:36 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Folks,
I'm about to commit up a non-breaking solution.
In bind, you can call:
BindHelpers.bindNodes.value: List[NodeSeq]
BindHelpers.currentNode.value: Elem
bindNodes is a list of the nodes that were passed into bind with the more
current node at the head of the list. If you're doing hierarchical
binding,
you can see all the nodes that were passed into bind this was.
currentNode is available to the BindParam and it contains the parent Elem
to
the NodeSeq that was passed into your BindParam. You can inspect
attributes
to your heart's content.
Give it an hour or two for these changes to make their way through
Hudson.
Thanks,
David
On Tue, Jan 6, 2009 at 4:50 AM, Marc Boschma
marc+lift...@boschma.cx marc%2blift...@boschma.cx
marc%2blift...@boschma.cx marc%252blift...@boschma.cx
wrote:
I've just had a thought as to how to make it not a breaking change.
Leave your change calcValue(s.child) I just call calcValue(s)
change:
case class FuncBindParam(name: String, value: NodeSeq = NodeSeq)
extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in)
}
to:
case class FuncBindParam(name: String, value: NodeSeq = NodeSeq)
extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.child)
}
That should prevent old code breaking... which would be a good
thing(tm) given the amount of code that uses bind(...)
then create something like:
case class FuncMetaDataBindParam(name: String, value: (MetaData,
NodeSeq) = NodeSeq) extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.attributes,
in.child)
}
along with adding to class SuperArrowAssoc...
def -(in: (MetaData, NodeSeq) = NodeSeq) =
FuncMetaDataBindParam(name, in)
That would be fairly clean...
-
Maybe for those that actually want the full node add:
case class FuncBoxBindParam(name: String, value: Box(NodeSeq) =
NodeSeq) extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(Full(in))
}
and you could go nuts and:
case class FuncPrefixAndLabelBindParam(name: String, value:
(String, String, NodeSeq) = NodeSeq) extends Tuple2(name, value) with
BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.prefix, in.label,
in.child)
}
etc...
On 06/01/2009, at 10:51 PM, Marc Boschma wrote:
(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
marc+lift...@boschma.cxmarc%2blift...@boschma.cx
marc%2blift...@boschma.cx marc%252blift...@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
[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)
On Tue, Jan 6, 2009 at 10:28 AM, Marius marius.dan...@gmail.com wrote:
On Jan 6, 7:15 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
I also added
BindHelpers.attr(tag): Option[NodeSeq]
so you can do something like:
span class={BindHelpers.attr(class).../span
and:
BindHelpers.attr(prefix, tag)
I think it is committed to curAttr which personally I'm not a fan ...
Doyou mind if I change it to attr or nodeAttr ?
Go for it.
Thanks,
David
On Tue, Jan 6, 2009 at 9:13 AM, Marius marius.dan...@gmail.com wrote:
Very cool Dave !
thx,
Marius
On Jan 6, 4:36 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Folks,
I'm about to commit up a non-breaking solution.
In bind, you can call:
BindHelpers.bindNodes.value: List[NodeSeq]
BindHelpers.currentNode.value: Elem
bindNodes is a list of the nodes that were passed into bind with the
more
current node at the head of the list. If you're doing hierarchical
binding,
you can see all the nodes that were passed into bind this was.
currentNode is available to the BindParam and it contains the parent
Elem
to
the NodeSeq that was passed into your BindParam. You can inspect
attributes
to your heart's content.
Give it an hour or two for these changes to make their way through
Hudson.
Thanks,
David
On Tue, Jan 6, 2009 at 4:50 AM, Marc Boschma
marc+lift...@boschma.cx marc%2blift...@boschma.cx
marc%2blift...@boschma.cx marc%252blift...@boschma.cx
marc%2blift...@boschma.cx marc%252blift...@boschma.cx
marc%252blift...@boschma.cx marc%25252blift...@boschma.cx
wrote:
I've just had a thought as to how to make it not a breaking change.
Leave your change calcValue(s.child) I just call calcValue(s)
change:
case class FuncBindParam(name: String, value: NodeSeq = NodeSeq)
extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in)
}
to:
case class FuncBindParam(name: String, value: NodeSeq = NodeSeq)
extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.child)
}
That should prevent old code breaking... which would be a good
thing(tm) given the amount of code that uses bind(...)
then create something like:
case class FuncMetaDataBindParam(name: String, value: (MetaData,
NodeSeq) = NodeSeq) extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.attributes,
in.child)
}
along with adding to class SuperArrowAssoc...
def -(in: (MetaData, NodeSeq) = NodeSeq) =
FuncMetaDataBindParam(name, in)
That would be fairly clean...
-
Maybe for those that actually want the full node add:
case class FuncBoxBindParam(name: String, value: Box(NodeSeq) =
NodeSeq) extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(Full(in))
}
and you could go nuts and:
case class FuncPrefixAndLabelBindParam(name: String, value:
(String, String, NodeSeq) = NodeSeq) extends Tuple2(name, value)
with
BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.prefix,
in.label,
in.child)
}
etc...
On 06/01/2009, at 10:51 PM, Marc Boschma wrote:
(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
marc+lift...@boschma.cxmarc%2blift...@boschma.cx
marc%2blift...@boschma.cx marc%252blift...@boschma.cx
marc%2blift...@boschma.cx marc%252blift...@boschma.cx
marc%252blift...@boschma.cx marc%25252blift...@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
[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)
Ok ... i just committed some changes:
1. Renamed curAttr to attr
2. The BindHelpers vals are now private but we expose two functions
currentNode and bindNodes
Br's,
Marius
On Jan 6, 8:37 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Tue, Jan 6, 2009 at 10:28 AM, Marius marius.dan...@gmail.com wrote:
On Jan 6, 7:15 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
I also added
BindHelpers.attr(tag): Option[NodeSeq]
so you can do something like:
span class={BindHelpers.attr(class).../span
and:
BindHelpers.attr(prefix, tag)
I think it is committed to curAttr which personally I'm not a fan ...
Doyou mind if I change it to attr or nodeAttr ?
Go for it.
Thanks,
David
On Tue, Jan 6, 2009 at 9:13 AM, Marius marius.dan...@gmail.com wrote:
Very cool Dave !
thx,
Marius
On Jan 6, 4:36 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Folks,
I'm about to commit up a non-breaking solution.
In bind, you can call:
BindHelpers.bindNodes.value: List[NodeSeq]
BindHelpers.currentNode.value: Elem
bindNodes is a list of the nodes that were passed into bind with the
more
current node at the head of the list. If you're doing hierarchical
binding,
you can see all the nodes that were passed into bind this was.
currentNode is available to the BindParam and it contains the parent
Elem
to
the NodeSeq that was passed into your BindParam. You can inspect
attributes
to your heart's content.
Give it an hour or two for these changes to make their way through
Hudson.
Thanks,
David
On Tue, Jan 6, 2009 at 4:50 AM, Marc Boschma
marc+lift...@boschma.cx marc%2blift...@boschma.cx
marc%2blift...@boschma.cx marc%252blift...@boschma.cx
marc%2blift...@boschma.cx marc%252blift...@boschma.cx
marc%252blift...@boschma.cx marc%25252blift...@boschma.cx
wrote:
I've just had a thought as to how to make it not a breaking change.
Leave your change calcValue(s.child) I just call calcValue(s)
change:
case class FuncBindParam(name: String, value: NodeSeq = NodeSeq)
extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in)
}
to:
case class FuncBindParam(name: String, value: NodeSeq = NodeSeq)
extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.child)
}
That should prevent old code breaking... which would be a good
thing(tm) given the amount of code that uses bind(...)
then create something like:
case class FuncMetaDataBindParam(name: String, value: (MetaData,
NodeSeq) = NodeSeq) extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.attributes,
in.child)
}
along with adding to class SuperArrowAssoc...
def -(in: (MetaData, NodeSeq) = NodeSeq) =
FuncMetaDataBindParam(name, in)
That would be fairly clean...
-
Maybe for those that actually want the full node add:
case class FuncBoxBindParam(name: String, value: Box(NodeSeq) =
NodeSeq) extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(Full(in))
}
and you could go nuts and:
case class FuncPrefixAndLabelBindParam(name: String, value:
(String, String, NodeSeq) = NodeSeq) extends Tuple2(name, value)
with
BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.prefix,
in.label,
in.child)
}
etc...
On 06/01/2009, at 10:51 PM, Marc Boschma wrote:
(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
marc+lift...@boschma.cxmarc%2blift...@boschma.cx
marc%2blift...@boschma.cx marc%252blift...@boschma.cx
marc%2blift...@boschma.cx marc%252blift...@boschma.cx
marc%252blift...@boschma.cx marc%25252blift...@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
[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)
On Tue, Jan 6, 2009 at 11:16 AM, Marius marius.dan...@gmail.com wrote:
Ok ... i just committed some changes:
1. Renamed curAttr to attr
2. The BindHelpers vals are now private but we expose two functions
currentNode and bindNodes
Cool beans!
Br's,
Marius
On Jan 6, 8:37 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Tue, Jan 6, 2009 at 10:28 AM, Marius marius.dan...@gmail.com wrote:
On Jan 6, 7:15 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
I also added
BindHelpers.attr(tag): Option[NodeSeq]
so you can do something like:
span class={BindHelpers.attr(class).../span
and:
BindHelpers.attr(prefix, tag)
I think it is committed to curAttr which personally I'm not a fan ...
Doyou mind if I change it to attr or nodeAttr ?
Go for it.
Thanks,
David
On Tue, Jan 6, 2009 at 9:13 AM, Marius marius.dan...@gmail.com
wrote:
Very cool Dave !
thx,
Marius
On Jan 6, 4:36 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Folks,
I'm about to commit up a non-breaking solution.
In bind, you can call:
BindHelpers.bindNodes.value: List[NodeSeq]
BindHelpers.currentNode.value: Elem
bindNodes is a list of the nodes that were passed into bind with
the
more
current node at the head of the list. If you're doing
hierarchical
binding,
you can see all the nodes that were passed into bind this was.
currentNode is available to the BindParam and it contains the
parent
Elem
to
the NodeSeq that was passed into your BindParam. You can inspect
attributes
to your heart's content.
Give it an hour or two for these changes to make their way
through
Hudson.
Thanks,
David
On Tue, Jan 6, 2009 at 4:50 AM, Marc Boschma
marc+lift...@boschma.cx marc%2blift...@boschma.cx
marc%2blift...@boschma.cx marc%252blift...@boschma.cx
marc%2blift...@boschma.cx marc%252blift...@boschma.cx
marc%252blift...@boschma.cx marc%25252blift...@boschma.cx
marc%2blift...@boschma.cx marc%252blift...@boschma.cx
marc%252blift...@boschma.cx marc%25252blift...@boschma.cx
marc%252blift...@boschma.cx marc%25252blift...@boschma.cx
marc%25252blift...@boschma.cx marc%2525252blift...@boschma.cx
wrote:
I've just had a thought as to how to make it not a breaking
change.
Leave your change calcValue(s.child) I just call calcValue(s)
change:
case class FuncBindParam(name: String, value: NodeSeq =
NodeSeq)
extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in)
}
to:
case class FuncBindParam(name: String, value: NodeSeq =
NodeSeq)
extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.child)
}
That should prevent old code breaking... which would be a good
thing(tm) given the amount of code that uses bind(...)
then create something like:
case class FuncMetaDataBindParam(name: String, value:
(MetaData,
NodeSeq) = NodeSeq) extends Tuple2(name, value) with BindParam
{
def calcValue(in: NodeSeq): NodeSeq = value(in.attributes,
in.child)
}
along with adding to class SuperArrowAssoc...
def -(in: (MetaData, NodeSeq) = NodeSeq) =
FuncMetaDataBindParam(name, in)
That would be fairly clean...
-
Maybe for those that actually want the full node add:
case class FuncBoxBindParam(name: String, value: Box(NodeSeq)
=
NodeSeq) extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(Full(in))
}
and you could go nuts and:
case class FuncPrefixAndLabelBindParam(name: String, value:
(String, String, NodeSeq) = NodeSeq) extends Tuple2(name,
value)
with
BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.prefix,
in.label,
in.child)
}
etc...
On 06/01/2009, at 10:51 PM, Marc Boschma wrote:
(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
marc+lift...@boschma.cxmarc%2blift...@boschma.cx
marc%2blift...@boschma.cx marc%252blift...@boschma.cx
marc%2blift...@boschma.cx marc%252blift...@boschma.cx
marc%252blift...@boschma.cx marc%25252blift...@boschma.cx
marc%2blift...@boschma.cx marc%252blift...@boschma.cx
marc%252blift...@boschma.cx marc%25252blift...@boschma.cx
marc%252blift...@boschma.cx marc%25252blift...@boschma.cx
marc%25252blift...@boschma.cx marc%2525252blift...@boschma.cx
wrote:
[Lift] Re: Can or Box or something else
Can is not an Option and to call it so in any way is an error of misintegration. Indeed it would be an error to replace Option with Can - they are completely different algebras. Either is kinded * - * - * so cannot possible be isomorphic and cannot possibly have map, flatMap etc (though it can have a bifunctor map being covariant in both type arguments). However, Either.LeftProjection and Either.RightProjection are kinded * - * and are both covariant functors and monads, hence map, flatMap etc. are available. e.g. for(x - either.left) ... is valid, try it. Of mild interest, it is possible to construct an isomorphism to Can using both Either and Option. Indeed, it is possible to construct an isomorphism to Option using Either e.g. forall A. Option[A] ≡ Either [Unit, A] so it is possible using Either alone. I'll leave both as reader exercises. On Dec 21 2008, 5:15 am, Oliver Lambert ola...@gmail.com wrote: Ok so Can is not either an Either or an Option, its a Can. I kind of wondered when I first used Can, and it was described as an enhanced Option, why it wasn't called something like Option+ with None, Some and Failure. On 21/12/2008, at 5:47 AM, David Pollak wrote: Can has map, flatMap, filter etc. So it can be used in a for comphrension. I don't believe Either has those methods. Further, Can has a bunch of helpers to turn Empty into Failure On Dec 20, 2008 10:33 AM, Oliver Lambert ola...@gmail.com wrote: Is Can a little less like Option and more like scala.Either, where the left side is used to indicate failure? On 21/12/2008, at 1:43 AM, David Pollak wrote: Folks, Over the year that Lift has had Can[T... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Can or Box or something else
Tony, Can (now Box) is not an Either. David On Tue, Jan 6, 2009 at 2:37 PM, Tony Morris tonymor...@gmail.com wrote: Can is not an Option and to call it so in any way is an error of misintegration. Indeed it would be an error to replace Option with Can - they are completely different algebras. Either is kinded * - * - * so cannot possible be isomorphic and cannot possibly have map, flatMap etc (though it can have a bifunctor map being covariant in both type arguments). However, Either.LeftProjection and Either.RightProjection are kinded * - * and are both covariant functors and monads, hence map, flatMap etc. are available. e.g. for(x - either.left) ... is valid, try it. Of mild interest, it is possible to construct an isomorphism to Can using both Either and Option. Indeed, it is possible to construct an isomorphism to Option using Either e.g. forall A. Option[A] ≡ Either [Unit, A] so it is possible using Either alone. I'll leave both as reader exercises. On Dec 21 2008, 5:15 am, Oliver Lambert ola...@gmail.com wrote: Ok so Can is not either an Either or an Option, its a Can. I kind of wondered when I first used Can, and it was described as an enhanced Option, why it wasn't called something like Option+ with None, Some and Failure. On 21/12/2008, at 5:47 AM, David Pollak wrote: Can has map, flatMap, filter etc. So it can be used in a for comphrension. I don't believe Either has those methods. Further, Can has a bunch of helpers to turn Empty into Failure On Dec 20, 2008 10:33 AM, Oliver Lambert ola...@gmail.com wrote: Is Can a little less like Option and more like scala.Either, where the left side is used to indicate failure? On 21/12/2008, at 1:43 AM, David Pollak wrote: Folks, Over the year that Lift has had Can[T... -- Lift, the simply functional web framework http://liftweb.net Collaborative Task Management http://much4.us 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 -~--~~~~--~~--~--~---
[Lift] Re: Can or Box or something else
It's an Option. It contains a value or it doesn't. In the case that it does not contain a value, it may contain out of band information. This is not any different from None which contains information. It contains the information that it lacks information. Sure, you can write Option[T] as Either[T, Nothing], but the value of only having on type is lost. On Tue, Jan 6, 2009 at 2:59 PM, Tony Morris tonymor...@gmail.com wrote: Right, that's what Oliver said and I was reinforcing it with deductive reasoning. It is also not Option. It is something else altogether. Nevertheless, an isomorphism can easily be written with Either alone (ignoring bottoms). So in some loose sense it is an Either. -- Tony Morris http://tmorris.net/ S, K and I ought to be enough for anybody. David Pollak wrote: Tony, Can (now Box) is not an Either. David On Tue, Jan 6, 2009 at 2:37 PM, Tony Morris tonymor...@gmail.com mailto:tonymor...@gmail.com wrote: Can is not an Option and to call it so in any way is an error of misintegration. Indeed it would be an error to replace Option with Can - they are completely different algebras. Either is kinded * - * - * so cannot possible be isomorphic and cannot possibly have map, flatMap etc (though it can have a bifunctor map being covariant in both type arguments). However, Either.LeftProjection and Either.RightProjection are kinded * - * and are both covariant functors and monads, hence map, flatMap etc. are available. e.g. for(x - either.left) ... is valid, try it. Of mild interest, it is possible to construct an isomorphism to Can using both Either and Option. Indeed, it is possible to construct an isomorphism to Option using Either e.g. forall A. Option[A] ≡ Either [Unit, A] so it is possible using Either alone. I'll leave both as reader exercises. On Dec 21 2008, 5:15 am, Oliver Lambert ola...@gmail.com mailto:ola...@gmail.com wrote: Ok so Can is not either an Either or an Option, its a Can. I kind of wondered when I first used Can, and it was described as an enhanced Option, why it wasn't called something like Option+ with None, Some and Failure. On 21/12/2008, at 5:47 AM, David Pollak wrote: Can has map, flatMap, filter etc. So it can be used in a for comphrension. I don't believe Either has those methods. Further, Can has a bunch of helpers to turn Empty into Failure On Dec 20, 2008 10:33 AM, Oliver Lambert ola...@gmail.com mailto:ola...@gmail.com wrote: Is Can a little less like Option and more like scala.Either, where the left side is used to indicate failure? On 21/12/2008, at 1:43 AM, David Pollak wrote: Folks, Over the year that Lift has had Can[T... -- Lift, the simply functional web framework http://liftweb.net Collaborative Task Management http://much4.us Follow me: http://twitter.com/dpp Git some: http://github.com/dpp -- Lift, the simply functional web framework http://liftweb.net Collaborative Task Management http://much4.us 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 -~--~~~~--~~--~--~---
[Lift] Re: Can or Box or something else
No this is a mistake. Can is not an Option. Indeed it is (almost)
impossible to write Can using Option (if you are familiar with Peano
Arithmetic you will understand the need to qualify with almost). There
is an arrow from forall A. Can[A] to Option[A] but not from forall A.
Option[A] to Can[A] (easily) - try it for yourself. To suggest that
Can is an Option (or an Option with more features or an Either) is
a mistake of misintegration (Peikoff DIM Hypothesis). Indeed the Can
algebra has nothing to do with Option (except for the aforementioned
function). There is no isomorphism between Can and Option - they are
not the same, not even close.
Here is a bit of code for fun. Note the bijective function using
Either alone:
sealed trait T[+A] {
val e: Either[(String, T[Throwable], List[(String, Throwable)],
Either[A, Unit]]
// bijection to e
val c: Can[A] = e match {
case Left(m, e, c) = Failure(m, e,
// Can makes the mistake of using a data constructor as a type.
// Unfortunately Scala permits this.
c map toFailure)
case Right(e) = e match {
case Left(a) = Full(a)
case Right(_) = Empty
}
}
}
object T {
// construct with Either or Can
}
--
Tony Morris
http://tmorris.net/
S, K and I ought to be enough for anybody.
David Pollak wrote:
It's an Option.
It contains a value or it doesn't. In the case that it does not
contain a value, it may contain out of band information. This is
not any different from None which contains information. It
contains the information that it lacks information.
Sure, you can write Option[T] as Either[T, Nothing], but the value
of only having on type is lost.
On Tue, Jan 6, 2009 at 2:59 PM, Tony Morris tonymor...@gmail.com
mailto:tonymor...@gmail.com wrote:
Right, that's what Oliver said and I was reinforcing it with
deductive reasoning. It is also not Option. It is something else
altogether. Nevertheless, an isomorphism can easily be written with
Either alone (ignoring bottoms). So in some loose sense it is an
Either.
-- Tony Morris http://tmorris.net/
S, K and I ought to be enough for anybody.
David Pollak wrote:
Tony,
Can (now Box) is not an Either.
David
On Tue, Jan 6, 2009 at 2:37 PM, Tony Morris
tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
wrote:
Can is not an Option and to call it so in any way is an error of
misintegration. Indeed it would be an error to replace Option
with
Can - they are completely different algebras. Either is kinded *
- * - * so cannot possible be isomorphic and cannot possibly
have
map, flatMap etc (though it can have a bifunctor map being
covariant in both type arguments). However, Either.LeftProjection
and Either.RightProjection are kinded * - * and are both
covariant
functors and monads, hence map, flatMap etc. are available. e.g.
for(x - either.left) ... is valid, try it.
Of mild interest, it is possible to construct an isomorphism
to Can
using both Either and Option. Indeed, it is possible to construct
an isomorphism to Option using Either e.g. forall A. Option[A] ≡
Either [Unit, A] so it is possible using Either alone. I'll
leave both as reader exercises.
On Dec 21 2008, 5:15 am, Oliver Lambert ola...@gmail.com
mailto:ola...@gmail.com
mailto:ola...@gmail.com mailto:ola...@gmail.com wrote:
Ok so Can is not either an Either or an Option, its a Can. I
kind of
wondered when I first used Can, and it was described as an
enhanced
Option, why it wasn't called something like Option+ with
None, Some
and Failure.
On 21/12/2008, at 5:47 AM, David Pollak wrote:
Can has map, flatMap, filter etc. So it can be used in a for
comphrension. I don't believe Either has those methods.
Further,
Can has a bunch of helpers to turn Empty into Failure
On Dec 20, 2008 10:33 AM, Oliver Lambert ola...@gmail.com
mailto:ola...@gmail.com
mailto:ola...@gmail.com mailto:ola...@gmail.com wrote:
Is Can a little less like Option and more like scala.Either,
where
the left side is used to indicate failure? On 21/12/2008, at
1:43 AM, David Pollak wrote: Folks,
Over the
year that Lift has had Can[T...
-- Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us Follow me:
http://twitter.com/dpp Git some: http://github.com/dpp
-- Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us 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
-~--~~~~--~~--~--~---
[Lift] Re: Can or Box or something else
It depends on what the meaning of is is.
If Option were not sealed, Can could be implemented as an Option... by
adding Failure and Empty as subclasses of None. In this (OO) sense, a Can is
an option.
In the algebraic sense, then you're probably right that a Can is not an
Option.
--j
On Tue, Jan 6, 2009 at 5:23 PM, Tony Morris tonymor...@gmail.com wrote:
No this is a mistake. Can is not an Option. Indeed it is (almost)
impossible to write Can using Option (if you are familiar with Peano
Arithmetic you will understand the need to qualify with almost). There
is an arrow from forall A. Can[A] to Option[A] but not from forall A.
Option[A] to Can[A] (easily) - try it for yourself. To suggest that
Can is an Option (or an Option with more features or an Either) is
a mistake of misintegration (Peikoff DIM Hypothesis). Indeed the Can
algebra has nothing to do with Option (except for the aforementioned
function). There is no isomorphism between Can and Option - they are
not the same, not even close.
Here is a bit of code for fun. Note the bijective function using
Either alone:
sealed trait T[+A] {
val e: Either[(String, T[Throwable], List[(String, Throwable)],
Either[A, Unit]]
// bijection to e
val c: Can[A] = e match {
case Left(m, e, c) = Failure(m, e,
// Can makes the mistake of using a data constructor as a type.
// Unfortunately Scala permits this.
c map toFailure)
case Right(e) = e match {
case Left(a) = Full(a)
case Right(_) = Empty
}
}
}
object T {
// construct with Either or Can
}
--
Tony Morris
http://tmorris.net/
S, K and I ought to be enough for anybody.
David Pollak wrote:
It's an Option.
It contains a value or it doesn't. In the case that it does not
contain a value, it may contain out of band information. This is
not any different from None which contains information. It
contains the information that it lacks information.
Sure, you can write Option[T] as Either[T, Nothing], but the value
of only having on type is lost.
On Tue, Jan 6, 2009 at 2:59 PM, Tony Morris tonymor...@gmail.com
mailto:tonymor...@gmail.com wrote:
Right, that's what Oliver said and I was reinforcing it with
deductive reasoning. It is also not Option. It is something else
altogether. Nevertheless, an isomorphism can easily be written with
Either alone (ignoring bottoms). So in some loose sense it is an
Either.
-- Tony Morris http://tmorris.net/
S, K and I ought to be enough for anybody.
David Pollak wrote:
Tony,
Can (now Box) is not an Either.
David
On Tue, Jan 6, 2009 at 2:37 PM, Tony Morris
tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
wrote:
Can is not an Option and to call it so in any way is an error of
misintegration. Indeed it would be an error to replace Option
with
Can - they are completely different algebras. Either is kinded *
- * - * so cannot possible be isomorphic and cannot possibly
have
map, flatMap etc (though it can have a bifunctor map being
covariant in both type arguments). However, Either.LeftProjection
and Either.RightProjection are kinded * - * and are both
covariant
functors and monads, hence map, flatMap etc. are available. e.g.
for(x - either.left) ... is valid, try it.
Of mild interest, it is possible to construct an isomorphism
to Can
using both Either and Option. Indeed, it is possible to construct
an isomorphism to Option using Either e.g. forall A. Option[A] ≡
Either [Unit, A] so it is possible using Either alone. I'll
leave both as reader exercises.
On Dec 21 2008, 5:15 am, Oliver Lambert ola...@gmail.com
mailto:ola...@gmail.com
mailto:ola...@gmail.com mailto:ola...@gmail.com wrote:
Ok so Can is not either an Either or an Option, its a Can. I
kind of
wondered when I first used Can, and it was described as an
enhanced
Option, why it wasn't called something like Option+ with
None, Some
and Failure.
On 21/12/2008, at 5:47 AM, David Pollak wrote:
Can has map, flatMap, filter etc. So it can be used in a for
comphrension. I don't believe Either has those methods.
Further,
Can has a bunch of helpers to turn Empty into Failure
On Dec 20, 2008 10:33 AM, Oliver Lambert ola...@gmail.com
mailto:ola...@gmail.com
mailto:ola...@gmail.com mailto:ola...@gmail.com wrote:
Is Can a little less like Option and more like scala.Either,
where
the left side is used to indicate failure? On 21/12/2008, at
1:43 AM, David Pollak wrote: Folks,
Over the
year that Lift has had Can[T...
-- Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us Follow me:
http://twitter.com/dpp Git some: http://github.com/dpp
-- Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us Follow me:
http://twitter.com/dpp Git some:
[Lift] Re: Can or Box or something else
When talking about data types is means is congruent to or is
isomorphic to. You are not free to use is arbitrarily, since if you
are then Can is anything I want it to be.
Since equivalence can be broken into an implication both ways e.g. A
- B and B - A then it is quite easy to test if Can is an Option.
def f[A](o: Option[A]): Can[A] // this should be total and bijective
def g[A](c: Can[A]): Option[A] // this should be total and bijective
The use of = in function signatures means logical implication. Does
Can imply Option? Yes (you can complete the g function). Does Option
imply Can? No (you cannot complete the f function). Therefore, Can is
not an Option. It was not even close (lack of totality in this test is
catastrophic).
If you want to try to save this notion of Well Can is a something,
then I have already pointed out a suggestion. Try to think of others,
but do not say that Can is an Option - it is not, not even close. Poor
Oliver was all confuzzled when he popped this one to me the other day.
--
Tony Morris
http://tmorris.net/
S, K and I ought to be enough for anybody.
Jorge Ortiz wrote:
It depends on what the meaning of is is.
If Option were not sealed, Can could be implemented as an
Option... by adding Failure and Empty as subclasses of None. In
this (OO) sense, a Can is an option.
In the algebraic sense, then you're probably right that a Can is
not an Option.
--j
On Tue, Jan 6, 2009 at 5:23 PM, Tony Morris tonymor...@gmail.com
mailto:tonymor...@gmail.com wrote:
No this is a mistake. Can is not an Option. Indeed it is (almost)
impossible to write Can using Option (if you are familiar with
Peano Arithmetic you will understand the need to qualify with
almost). There is an arrow from forall A. Can[A] to Option[A] but
not from forall A. Option[A] to Can[A] (easily) - try it for
yourself. To suggest that Can is an Option (or an Option with more
features or an Either) is a mistake of misintegration (Peikoff
DIM Hypothesis). Indeed the Can algebra has nothing to do with
Option (except for the aforementioned function). There is no
isomorphism between Can and Option - they are not the same, not
even close.
Here is a bit of code for fun. Note the bijective function using
Either alone:
sealed trait T[+A] { val e: Either[(String, T[Throwable],
List[(String, Throwable)], Either[A, Unit]]
// bijection to e val c: Can[A] = e match { case Left(m, e, c) =
Failure(m, e, // Can makes the mistake of using a data constructor
as a type. // Unfortunately Scala permits this. c map toFailure)
case Right(e) = e match { case Left(a) = Full(a) case Right(_) =
Empty } } }
object T { // construct with Either or Can }
-- Tony Morris http://tmorris.net/
S, K and I ought to be enough for anybody.
David Pollak wrote:
It's an Option.
It contains a value or it doesn't. In the case that it does not
contain a value, it may contain out of band information. This is
not any different from None which contains information. It
contains the information that it lacks information.
Sure, you can write Option[T] as Either[T, Nothing], but the
value of only having on type is lost.
On Tue, Jan 6, 2009 at 2:59 PM, Tony Morris
tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
wrote:
Right, that's what Oliver said and I was reinforcing it with
deductive reasoning. It is also not Option. It is something else
altogether. Nevertheless, an isomorphism can easily be written
with
Either alone (ignoring bottoms). So in some loose sense it is an
Either.
-- Tony Morris http://tmorris.net/
S, K and I ought to be enough for anybody.
David Pollak wrote:
Tony,
Can (now Box) is not an Either.
David
On Tue, Jan 6, 2009 at 2:37 PM, Tony Morris
tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
wrote:
Can is not an Option and to call it so in any way is an error
of misintegration. Indeed it would be an error to replace
Option
with
Can - they are completely different algebras. Either is kinded
* - * - * so cannot possible be isomorphic and cannot
possibly
have
map, flatMap etc (though it can have a bifunctor map being
covariant in both type arguments). However,
Either.LeftProjection and Either.RightProjection are kinded *
- * and are both
covariant
functors and monads, hence map, flatMap etc. are available.
e.g. for(x - either.left) ... is valid, try it.
Of mild interest, it is possible to construct an isomorphism
to Can
using both Either and Option. Indeed, it is possible to
construct an isomorphism to Option using Either e.g. forall A.
Option[A] ≡ Either [Unit, A] so it is possible using Either
alone. I'll leave both as reader exercises.
On Dec 21 2008, 5:15 am, Oliver Lambert ola...@gmail.com
mailto:ola...@gmail.com
[Lift] Re: Can or Box or something else
On Tue, Jan 6, 2009 at 11:23 PM, Tony Morris tonymor...@gmail.com wrote: No this is a mistake. Can is not an Option. Indeed it is (almost) impossible to write Can using Option (if you are familiar with Peano Arithmetic you will understand the need to qualify with almost). While you're right in a (very) narrowly technical sense you're missing the point that Lift's Can has functionality that is very closely related to a combination of Option and Either in a touchy-feely pragmatic getting-useful-things-actually-done sort of sense. To prove the point, here, http://www.milessabin.com/misc/Chain.scala is something I put together a while ago which can be used in a very similar way to Can (at least, I expect that's the case ... I haven't worked with Lift so I can't be sure) but which only exposes Option and Either in it's public interface. It's also sufficiently Monad like to get along nicely with for comprehensions. Given the likelihood of confusion between Can and Option (irrespective the algebraic niceties) I wish Lift had gone for something more like that than a rename to Box. Cheers, Miles -- Miles Sabin tel:+44 (0)1273 720 779 mobile: +44 (0)7813 944 528 skype: milessabin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Can or Box or something else
For most people, is does not always and exclusively mean bi-implication.
You are free to think this way, if you choose, but please don't impose your
Language Police on us.
--j
On Tue, Jan 6, 2009 at 5:49 PM, Tony Morris tonymor...@gmail.com wrote:
When talking about data types is means is congruent to or is
isomorphic to. You are not free to use is arbitrarily, since if you
are then Can is anything I want it to be.
Since equivalence can be broken into an implication both ways e.g. A
- B and B - A then it is quite easy to test if Can is an Option.
def f[A](o: Option[A]): Can[A] // this should be total and bijective
def g[A](c: Can[A]): Option[A] // this should be total and bijective
The use of = in function signatures means logical implication. Does
Can imply Option? Yes (you can complete the g function). Does Option
imply Can? No (you cannot complete the f function). Therefore, Can is
not an Option. It was not even close (lack of totality in this test is
catastrophic).
If you want to try to save this notion of Well Can is a something,
then I have already pointed out a suggestion. Try to think of others,
but do not say that Can is an Option - it is not, not even close. Poor
Oliver was all confuzzled when he popped this one to me the other day.
--
Tony Morris
http://tmorris.net/
S, K and I ought to be enough for anybody.
Jorge Ortiz wrote:
It depends on what the meaning of is is.
If Option were not sealed, Can could be implemented as an
Option... by adding Failure and Empty as subclasses of None. In
this (OO) sense, a Can is an option.
In the algebraic sense, then you're probably right that a Can is
not an Option.
--j
On Tue, Jan 6, 2009 at 5:23 PM, Tony Morris tonymor...@gmail.com
mailto:tonymor...@gmail.com wrote:
No this is a mistake. Can is not an Option. Indeed it is (almost)
impossible to write Can using Option (if you are familiar with
Peano Arithmetic you will understand the need to qualify with
almost). There is an arrow from forall A. Can[A] to Option[A] but
not from forall A. Option[A] to Can[A] (easily) - try it for
yourself. To suggest that Can is an Option (or an Option with more
features or an Either) is a mistake of misintegration (Peikoff
DIM Hypothesis). Indeed the Can algebra has nothing to do with
Option (except for the aforementioned function). There is no
isomorphism between Can and Option - they are not the same, not
even close.
Here is a bit of code for fun. Note the bijective function using
Either alone:
sealed trait T[+A] { val e: Either[(String, T[Throwable],
List[(String, Throwable)], Either[A, Unit]]
// bijection to e val c: Can[A] = e match { case Left(m, e, c) =
Failure(m, e, // Can makes the mistake of using a data constructor
as a type. // Unfortunately Scala permits this. c map toFailure)
case Right(e) = e match { case Left(a) = Full(a) case Right(_) =
Empty } } }
object T { // construct with Either or Can }
-- Tony Morris http://tmorris.net/
S, K and I ought to be enough for anybody.
David Pollak wrote:
It's an Option.
It contains a value or it doesn't. In the case that it does not
contain a value, it may contain out of band information. This is
not any different from None which contains information. It
contains the information that it lacks information.
Sure, you can write Option[T] as Either[T, Nothing], but the
value of only having on type is lost.
On Tue, Jan 6, 2009 at 2:59 PM, Tony Morris
tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
wrote:
Right, that's what Oliver said and I was reinforcing it with
deductive reasoning. It is also not Option. It is something else
altogether. Nevertheless, an isomorphism can easily be written
with
Either alone (ignoring bottoms). So in some loose sense it is an
Either.
-- Tony Morris http://tmorris.net/
S, K and I ought to be enough for anybody.
David Pollak wrote:
Tony,
Can (now Box) is not an Either.
David
On Tue, Jan 6, 2009 at 2:37 PM, Tony Morris
tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
wrote:
Can is not an Option and to call it so in any way is an error
of misintegration. Indeed it would be an error to replace
Option
with
Can - they are completely different algebras. Either is kinded
* - * - * so cannot possible be isomorphic and cannot
possibly
have
map, flatMap etc (though it can have a bifunctor map being
covariant in both type arguments). However,
Either.LeftProjection and Either.RightProjection are kinded *
- * and are both
covariant
functors and monads, hence map, flatMap etc. are available.
e.g. for(x - either.left) ... is valid, try it.
Of mild
[Lift] Flot Widget
Folks, I've just updated the Flot widget (which is pretty cool) to be more Lift-like. I've changed Option to Box to be consistent with Lift's use of Box unless there's a compelling reason to use Option. I've changed the code so it uses Lift's JavaScript helpers rather than doing manual string generation. I've also fixed the Flot example code so that it works. Thanks, David -- Lift, the simply functional web framework http://liftweb.net Collaborative Task Management http://much4.us 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 -~--~~~~--~~--~--~---
[Lift] Re: Can or Box or something else
Do any conversions exist to treat a Box[_] as an
Either[Option[_],Exception] or as an Option[_]? Are there any helper
functions that lift could benefit from by having these?
Also, anytime I see the line I leave this as an excercise to the
reader I feel like I'm being lectured :)
On Jan 6, 2009, at 7:38 PM, Jorge Ortiz jorge.or...@gmail.com wrote:
For most people, is does not always and exclusively mean bi-
implication. You are free to think this way, if you choose, but
please don't impose your Language Police on us.
--j
On Tue, Jan 6, 2009 at 5:49 PM, Tony Morris tonymor...@gmail.com
wrote:
When talking about data types is means is congruent to or is
isomorphic to. You are not free to use is arbitrarily, since if you
are then Can is anything I want it to be.
Since equivalence can be broken into an implication both ways e.g. A
- B and B - A then it is quite easy to test if Can is an Option.
def f[A](o: Option[A]): Can[A] // this should be total and bijective
def g[A](c: Can[A]): Option[A] // this should be total and bijective
The use of = in function signatures means logical implication. Does
Can imply Option? Yes (you can complete the g function). Does Option
imply Can? No (you cannot complete the f function). Therefore, Can is
not an Option. It was not even close (lack of totality in this test is
catastrophic).
If you want to try to save this notion of Well Can is a something,
then I have already pointed out a suggestion. Try to think of others,
but do not say that Can is an Option - it is not, not even close. Poor
Oliver was all confuzzled when he popped this one to me the other day.
--
Tony Morris
http://tmorris.net/
S, K and I ought to be enough for anybody.
Jorge Ortiz wrote:
It depends on what the meaning of is is.
If Option were not sealed, Can could be implemented as an
Option... by adding Failure and Empty as subclasses of None. In
this (OO) sense, a Can is an option.
In the algebraic sense, then you're probably right that a Can is
not an Option.
--j
On Tue, Jan 6, 2009 at 5:23 PM, Tony Morris tonymor...@gmail.com
mailto:tonymor...@gmail.com wrote:
No this is a mistake. Can is not an Option. Indeed it is (almost)
impossible to write Can using Option (if you are familiar with
Peano Arithmetic you will understand the need to qualify with
almost). There is an arrow from forall A. Can[A] to Option[A] but
not from forall A. Option[A] to Can[A] (easily) - try it for
yourself. To suggest that Can is an Option (or an Option with more
features or an Either) is a mistake of misintegration (Peikoff
DIM Hypothesis). Indeed the Can algebra has nothing to do with
Option (except for the aforementioned function). There is no
isomorphism between Can and Option - they are not the same, not
even close.
Here is a bit of code for fun. Note the bijective function using
Either alone:
sealed trait T[+A] { val e: Either[(String, T[Throwable],
List[(String, Throwable)], Either[A, Unit]]
// bijection to e val c: Can[A] = e match { case Left(m, e, c) =
Failure(m, e, // Can makes the mistake of using a data constructor
as a type. // Unfortunately Scala permits this. c map toFailure)
case Right(e) = e match { case Left(a) = Full(a) case Right(_) =
Empty } } }
object T { // construct with Either or Can }
-- Tony Morris http://tmorris.net/
S, K and I ought to be enough for anybody.
David Pollak wrote:
It's an Option.
It contains a value or it doesn't. In the case that it does not
contain a value, it may contain out of band information. This is
not any different from None which contains information. It
contains the information that it lacks information.
Sure, you can write Option[T] as Either[T, Nothing], but the
value of only having on type is lost.
On Tue, Jan 6, 2009 at 2:59 PM, Tony Morris
tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
wrote:
Right, that's what Oliver said and I was reinforcing it with
deductive reasoning. It is also not Option. It is something else
altogether. Nevertheless, an isomorphism can easily be written
with
Either alone (ignoring bottoms). So in some loose sense it is an
Either.
-- Tony Morris http://tmorris.net/
S, K and I ought to be enough for anybody.
David Pollak wrote:
Tony,
Can (now Box) is not an Either.
David
On Tue, Jan 6, 2009 at 2:37 PM, Tony Morris
tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
wrote:
Can is not an Option and to call it so in any way is an error
of misintegration. Indeed it would be an error to replace
Option
with
Can - they are completely different algebras. Either is kinded
* - * - * so cannot possible
[Lift] Re: Can or Box or something else
On Tue, Jan 6, 2009 at 5:27 PM, Josh Suereth joshua.suer...@gmail.comwrote:
Do any conversions exist to treat a Box[_] as an
Either[Option[_],Exception] or as an Option[_]? Are there any helper
functions that lift could benefit from by having these?
Box instances have a toOption method. Full - Some, Empty/Failure - None
The Box object has:
apply[T](in: Option[T]): Box[T] = in match {case Some(t) = Full(t) case _
= Empty}
There's an implicit conversion from Box to Option.
Also, anytime I see the line I leave this as an excercise to the reader I
feel like I'm being lectured :)
On Jan 6, 2009, at 7:38 PM, Jorge Ortiz jorge.or...@gmail.com wrote:
For most people, is does not always and exclusively mean
bi-implication. You are free to think this way, if you choose, but please
don't impose your Language Police on us.
--j
On Tue, Jan 6, 2009 at 5:49 PM, Tony Morris tonymor...@gmail.com
tonymor...@gmail.com wrote:
When talking about data types is means is congruent to or is
isomorphic to. You are not free to use is arbitrarily, since if you
are then Can is anything I want it to be.
Since equivalence can be broken into an implication both ways e.g. A
- B and B - A then it is quite easy to test if Can is an Option.
def f[A](o: Option[A]): Can[A] // this should be total and bijective
def g[A](c: Can[A]): Option[A] // this should be total and bijective
The use of = in function signatures means logical implication. Does
Can imply Option? Yes (you can complete the g function). Does Option
imply Can? No (you cannot complete the f function). Therefore, Can is
not an Option. It was not even close (lack of totality in this test is
catastrophic).
If you want to try to save this notion of Well Can is a something,
then I have already pointed out a suggestion. Try to think of others,
but do not say that Can is an Option - it is not, not even close. Poor
Oliver was all confuzzled when he popped this one to me the other day.
--
Tony Morris
http://tmorris.net/http://tmorris.net/
S, K and I ought to be enough for anybody.
Jorge Ortiz wrote:
It depends on what the meaning of is is.
If Option were not sealed, Can could be implemented as an
Option... by adding Failure and Empty as subclasses of None. In
this (OO) sense, a Can is an option.
In the algebraic sense, then you're probably right that a Can is
not an Option.
--j
On Tue, Jan 6, 2009 at 5:23 PM, Tony Morris tonymor...@gmail.com
tonymor...@gmail.com
mailto: tonymor...@gmail.comtonymor...@gmail.com wrote:
No this is a mistake. Can is not an Option. Indeed it is (almost)
impossible to write Can using Option (if you are familiar with
Peano Arithmetic you will understand the need to qualify with
almost). There is an arrow from forall A. Can[A] to Option[A] but
not from forall A. Option[A] to Can[A] (easily) - try it for
yourself. To suggest that Can is an Option (or an Option with more
features or an Either) is a mistake of misintegration (Peikoff
DIM Hypothesis). Indeed the Can algebra has nothing to do with
Option (except for the aforementioned function). There is no
isomorphism between Can and Option - they are not the same, not
even close.
Here is a bit of code for fun. Note the bijective function using
Either alone:
sealed trait T[+A] { val e: Either[(String, T[Throwable],
List[(String, Throwable)], Either[A, Unit]]
// bijection to e val c: Can[A] = e match { case Left(m, e, c) =
Failure(m, e, // Can makes the mistake of using a data constructor
as a type. // Unfortunately Scala permits this. c map toFailure)
case Right(e) = e match { case Left(a) = Full(a) case Right(_) =
Empty } } }
object T { // construct with Either or Can }
-- Tony Morris http://tmorris.net/http://tmorris.net/
S, K and I ought to be enough for anybody.
David Pollak wrote:
It's an Option.
It contains a value or it doesn't. In the case that it does not
contain a value, it may contain out of band information. This is
not any different from None which contains information. It
contains the information that it lacks information.
Sure, you can write Option[T] as Either[T, Nothing], but the
value of only having on type is lost.
On Tue, Jan 6, 2009 at 2:59 PM, Tony Morris
tonymor...@gmail.comtonymor...@gmail.com mailto:tonymor...@gmail.com
tonymor...@gmail.com
mailto: tonymor...@gmail.comtonymor...@gmail.com
mailto:tonymor...@gmail.com
tonymor...@gmail.com
wrote:
Right, that's what Oliver said and I was reinforcing it with
deductive reasoning. It is also not Option. It is something else
altogether. Nevertheless, an isomorphism can easily be written
with
Either alone (ignoring bottoms). So in some loose sense it is an
Either.
-- Tony Morris http://tmorris.net/http://tmorris.net/
S, K and I ought to be enough for anybody.
David Pollak wrote:
Tony,
Can (now Box) is not an Either.
David
[Lift] Re: Flot Widget
Awesome, I just looked at the Flot+Comet stuff, some cool stuff could be done with that. Nice stuff Dave and Francois! On Jan 6, 8:15 pm, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, I've just updated the Flot widget (which is pretty cool) to be more Lift-like. I've changed Option to Box to be consistent with Lift's use of Box unless there's a compelling reason to use Option. I've changed the code so it uses Lift's JavaScript helpers rather than doing manual string generation. I've also fixed the Flot example code so that it works. Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Collaborative Task Managementhttp://much4.us 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 -~--~~~~--~~--~--~---
[Lift] Does memcache fit in here somewhere?
I'm keeping my eye on Lift, but I'm primarily a PHP guy as far as paying the bills goes. I've got a slightly better high-level understanding of things now versus a month or so ago, but I'm not sure where caching fits into the picture. In the LAMP world, it's standard practice to put memcache in front of your database server. It's pretty much a cache everything philosophy. Is this not encouraged with Lift? I assume there are more caching choices in the Java world such as ehcache, but I don't see them mentioned on the list. Bob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Does memcache fit in here somewhere?
On Tuesday 06 January 2009 20:15, David Pollak wrote: Bob, memcached is failure. ... Please look at this presentation. That's rather elliptic. Is there something less terse to go with it? Some more detailed paper or exposition of its thesis, perhaps? Thanks, David Randall Schulz --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)
Cool code! Works nicely...
Would it make sense to also add something similar to this from S.attr ?
def apply[T](what: String, f: String = T, default: = T): T =
apply(what).map(f) openOr default
ie maybe:
def apply[T](prefix: String, key: String, f: String = T):
Option[T] = apply(prefix, key).map(f)
def apply[T](key: String, f: String = T): Option[T] =
apply(key).map(f)
to BindHelpers.attr ?
Thinking about it should the applys of the two attr objects be aligned
(Option verses Box, etc) ? It would make the crafting of snippets and
bind functions in terms of access to attributes the same, dropping a
potential barrier to learning lift...
ie Maybe BindHelpers.attr should have applys with the following
signatures...
def apply(key: String): Box[String]
def apply(prefix: String, key: String): Box[String]
def apply(key: String, default: = String): String
def apply(prefix: String, key: String, default: = String): String
def apply[T](key: String, f: String = T, default: = T): T
def apply[T](prefix: String, key: String, f: String = T,
default: = T): T
Lastly, and maybe I am missing something here, but I take it for a
snippet a prefixed attribute isn't accessible via S.attr ???
Regards,
Marc
On 07/01/2009, at 6:54 AM, David Pollak wrote:
On Tue, Jan 6, 2009 at 11:16 AM, Marius marius.dan...@gmail.com
wrote:
Ok ... i just committed some changes:
1. Renamed curAttr to attr
2. The BindHelpers vals are now private but we expose two functions
currentNode and bindNodes
Cool beans!
Br's,
Marius
On Jan 6, 8:37 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Tue, Jan 6, 2009 at 10:28 AM, Marius marius.dan...@gmail.com
wrote:
On Jan 6, 7:15 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
I also added
BindHelpers.attr(tag): Option[NodeSeq]
so you can do something like:
span class={BindHelpers.attr(class).../span
and:
BindHelpers.attr(prefix, tag)
I think it is committed to curAttr which personally I'm not a
fan ...
Doyou mind if I change it to attr or nodeAttr ?
Go for it.
Thanks,
David
On Tue, Jan 6, 2009 at 9:13 AM, Marius
marius.dan...@gmail.com wrote:
Very cool Dave !
thx,
Marius
On Jan 6, 4:36 pm, David Pollak
feeder.of.the.be...@gmail.com
wrote:
Folks,
I'm about to commit up a non-breaking solution.
In bind, you can call:
BindHelpers.bindNodes.value: List[NodeSeq]
BindHelpers.currentNode.value: Elem
bindNodes is a list of the nodes that were passed into
bind with the
more
current node at the head of the list. If you're doing
hierarchical
binding,
you can see all the nodes that were passed into bind this
was.
currentNode is available to the BindParam and it contains
the parent
Elem
to
the NodeSeq that was passed into your BindParam. You can
inspect
attributes
to your heart's content.
Give it an hour or two for these changes to make their way
through
Hudson.
Thanks,
David
On Tue, Jan 6, 2009 at 4:50 AM, Marc Boschma
marc+lift...@boschma.cx marc%2blift...@boschma.cx
marc%2blift...@boschma.cx marc%252blift...@boschma.cx
marc%2blift...@boschma.cx marc%252blift...@boschma.cx
marc%252blift...@boschma.cx marc%25252blift...@boschma.cx
wrote:
I've just had a thought as to how to make it not a
breaking change.
Leave your change calcValue(s.child) I just call
calcValue(s)
change:
case class FuncBindParam(name: String, value: NodeSeq
= NodeSeq)
extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in)
}
to:
case class FuncBindParam(name: String, value: NodeSeq
= NodeSeq)
extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(in.child)
}
That should prevent old code breaking... which would be
a good
thing(tm) given the amount of code that uses bind(...)
then create something like:
case class FuncMetaDataBindParam(name: String, value:
(MetaData,
NodeSeq) = NodeSeq) extends Tuple2(name, value) with
BindParam {
def calcValue(in: NodeSeq): NodeSeq =
value(in.attributes,
in.child)
}
along with adding to class SuperArrowAssoc...
def -(in: (MetaData, NodeSeq) = NodeSeq) =
FuncMetaDataBindParam(name, in)
That would be fairly clean...
-
Maybe for those that actually want the full node add:
case class FuncBoxBindParam(name: String, value:
Box(NodeSeq) =
NodeSeq) extends Tuple2(name, value) with BindParam {
def calcValue(in: NodeSeq): NodeSeq = value(Full(in))
}
and you could go
