Why is that a boiler plate?

Usually in those functions you are building your domain objects,
calling setters etc when your function bound to the submit button is
called, you have your model built up and start processing it. One
other reason for those little functions is type-safety. Your function
is called with the proper parameter value and you just use it in a
type safe manner.

but if you don't like this you can still use jsonForm and in your
JsonHandler you have a Map with all your form fields.

Record framework for example has a Record.toForm function that is able
to serialize a Record into the form  markup (you can even provide your
own template) and you can specify your own function that will be
called when your generated form is submitted. Lift will automatically
build your Field-s our of submitted values, and in your processing
function you can do validation (see validation support in Record), and
do whatever else you want with it.


Br's,
Marius

On Jul 26, 12:18 am, 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?
>
> As a corollary to this question, are there other mechanisms available
> in Lift for form generation/processing?
>
> Cheers
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to