David Pollak <feeder.of.the.be...@gmail.com> writes: > Folks, > > I've completed the first pass at multi-page input Wizards in Lift. You can > see an example at: http://demo.liftweb.net/wiz
Great news! [...] > The building of HTML forms from the given field type is based on the type > (currently, there's support for String and Int, but more to come) and it's > based on plugable functions, so you can build date pickers that are > localized, etc. > > What needs to be done: > > - The naming (including the names that the various parts of the wizard > bind to) need a good going-over > - Support for many different input types (not just Int and String) > - Feedback I've been thinking about this for a while and haven't really reached anything concrete yet, but it overlaps enough with the wizard stuff that I might just throw it out here now: I think that form handling in Lift is too cumbersome. I.e. all the building blocks are there to create great forms, but it takes too much boilerplate code to achieve a nice result. I know forms are not sexy in the ways Comet & Ajax support is, but for many applications (ours included :-) it's where the major interactions with the user happens, so a good UX is essential. Here's my (ultimate) list of things that should be easy (for the developer) to do without too much fuzz: - Provide field level validations - including client side if possible - Provide form level validations - including client side - If the form contains Mapper fields, you should not have to respecify the validations - Render fields with proper markup (ie required fields should be indicated) - When a form is in error, retain values entered by the user - When a field is in error render it differently (ie red) with field specific error - Provide field level help (inline, popup etc) - Provide form level help - All fields and text should support i18n (ie both labels, text and for numeric and e.g date entries) I haven't looked closely at the wizard code yet, but it seems like it does provide some of these benefits. Some possible ideas: - Could be nice if the wizard code could be extended to generic forms. Wizards would just be a special case, with a sequence of forms and prev/next buttons etc. - I would very much like to see validations lifted to a higher level so that the same validation rule can be used for Mapper (and Record), forms & wizards. - Fields should be able to emit client side validations and code - Maybe we could introduce generic form fields (ie Number, Date etc) and they could be reused by the Mapper/Record fields. In this way, they would all share the same presentation logic (ie i18n formatting for display/editing, datepickers, more advanced dialogs etc) - Much more Thoughts? We'll soon be needing much of this in our app, so I'm willing to participate in this if there's any interest. /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
