Marius,
Maybe boiler plate is too strong a word, but every form example I've
seen follows the exact same pattern. The form support in Record sounds
interesting, though I'm always wary of mixing form handling in with
mapped objects. Also, not every form necessarily maps to a database
object. I'll probably still take a look at it though.
As for how, exactly, I would like my code to look... well, it could go
any number of way really. I like the option of having a form callback
that deals solely with a Map[String, String] of form fields. It's
inelegant, and loses some of the static checking the current solution
has, but it's flexible.
someSnippet(xml: NodeSeq) = {
bind("prefix", xml,
"fieldOne" -> SHtml.text( ... ),
"fieldTwo" -> SHtml.text( ... ),
"formSubmit" -> SHtml.submit("Submit", submitHandler))
}
submitHandler(fields: Map[String, String]) {
//grab things off the map, do processing
}
Like I said, not really elegant and this exact functionality can
already be achieved using the current setup but it has the advantage
of not relying on stored closures; the map would just be part of the
post request. As far as I can tell, and please correct me if I'm
wrong, behind the scenes Lift is storing these closures somehow and
associating them with a form via the name attributes. This idea really
scares me because it seems to have a very high potential for abuse and
it doesn't seem to be documented anywhere. For example, it was very to
use Firebug and modify the name attributes on my form to produce
unexpected behavior in my application. This means, as a developer, I
have to worry and protect myself against the case where any and all of
my field-associated closures were not called at all, even my submit
handler.
Maybe storing closures is beneficial or even necessary when dealing
with AJAX and Comet but for vanilla forms it seems unnecessarily
stateful. Why not just process the entire form as the request is made?
Cheers,
Devon
On Jul 26, 5:26 am, "marius d." <marius.dan...@gmail.com> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
