I hope to commit in the next few days code that makes a couple of similar asks
easier B"H.
But, to put the ball in your court, how exactly do you want your code to look?
If you write a complete sample usage I'll see what I can do to implement such
functionality.
Also, Kris, could you elaborate on how the first way would help track values
and how it would make the option case easier, and explain the second way better?
Thanks.
-------------------------------------
Kris Nuttycombe<kris.nuttyco...@gmail.com> wrote:
On Sat, Jul 25, 2009 at 3:18 PM, Devon Tucker<devonrtuc...@gmail.com> wrote:
>
> Hi all,
>
> I've been working with Lift for about a little while now; there are
> still plenty of aspects of Lift I haven't touched yet. One thing I am
> curious about at this point though is the rationale behind having one
> callback per field when generating forms. Each SHtml form element
> needs to be handed its own call back function. This strikes me as a
> kind of cumbersome, for instance the form examples on the Wiki and in
> the Exploring Lift book all follow this pattern:
>
> someSnippet(xml: NodeSeq) = {
> var fieldOne = ""
> var fieldTwo = ""
> def sumbitHandler() = { ... }
>
> bind("prefix", xml,
> "fieldOne" -> SHtml.text(fieldOne, fieldOne = _),
> "fieldTwo" -> SHtml.text(fieldTwo, fieldTwo = _),
> "formSubmit" -> SHtml.submit("Submit", submitHandler))
> }
>
> I've seen several examples of this exact pattern at this point and it
> makes the whole fieldOne = _ callback seem like needless boiler-plate.
> Why not allow for just one callback function that works over some
> object encapsulating an entire form? Am I missing something?
This is a pretty interesting question; I've sometimes wondered whether
the use of bare closures for this purpose isn't a bit too close to the
metal. It would be possible to do something like what you describe,
but the binding of each form element would still have to have some
reference to the variable being set. Now this could conceivably be
achieved in a few different ways:
You could have each bound variable, instead of being a regular Scala
variable, be an object extending some trait that the SHtml field
builders know about. This would mean that you'd just pass references
to those objects to the field builders, and they'd be automatically
mutated with the form field value on submit. The amount of boilerplate
-- maybe something like "object fieldOne extends StringField" -- would
be similar to what you get from the current situation. The one thing I
like about this is that the state of such a field could be tracked a
bit better; in the past I've found myself with a lot of code like the
following:
var fieldOne: Option[MyObject] = None
val options: Seq[(MyObject, String)] = ...
bind("prefix", xml,
"myselect" -> SHtml.selectObj(options, Empty, a => fieldOne = Some(a))
just to avoid mucking about with nulls, and this definitely gets laden
with boilerplate when you have a bunch of fields, particularly in the
handler function.
You could have the SHtml field builders return some sort of object
apart from an XML node, store that in a local val, and then have your
form-level callback refer to that value. This seems like an attractive
possibility to me because it could eliminate the need for mutable
variables entirely; the resulting objects could dynamically obtain
their submitted values from the Req when referenced by the callback
function.
Neither of these approaches exist yet, but you could build either one
of them atop the current framework, which I think is sort of one of
the main points of Lift at this stage in its development - it gives
you the most powerful tools it can, and one can build higher-level
abstractions atop what it provides.
Kris
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
