I've been using a library that works somewhat differently from Record
(bottom up rather than top down) and might work in a way more familiar to
some people. It provides a syntax something like
class FavouriteB extends Binder {
val yourName = bindString("yourName") // mandatory is the default
val yourNickname = bindStringOpt("yourNickname") // optional string
val donationDate = bindDate("donationDate")
}
It's strongly typed, provides options for optional fields and validation.
Rather than Record.toForm, the bind then just becomes something like
bind("favourite", xhtml, favouriteB.bindParams)
If someone expresses interested in using it, I would release it. I've been
sitting on it
because I'm not sure I want compete with Record, but, perhaps the two
approaches
could be complementary.
cheers
Oliver
On Mon, Jul 27, 2009 at 12:17 AM, Devon Tucker <devonrtuc...@gmail.com>wrote:
>
> 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
-~----------~----~----~----~------~----~------~--~---
