OK, so i just checked out:
http://github.com/dpp/liftweb/tree/dpp_issue_159_wizard
Looks pretty interesting. I know its a work in progress, but I have
the following thoughts right now (please dont crucify me for early
feedback!):
- Im confused why the Field traits from Record are not being used
here; they seem like a more logical abstract fit for what lift-wizard
is about... it would also cut down on field type coding in lift.
- Not a huge fan of using mapper directly - linking the wizard to the
mapper validations makes it pretty unusable from JPA, Record etc; it
should be as agnostic as possible.
- Its not obvious if toForm in the Wizard trait is going to be used,
but if so, is there any-way to get away from using xml literals and
move to bind(...) or similar?
- The next / prev / cancel / finish button elements should probably be
<input type="submit" value={...} />
- Line 433 in the Screen trait should be "method" not "mathod" ;-)
Just some thoughts - on the whole it looks very, very cool. Certainly
from my perspective there are a bunch of uses for this right out of
the blocks but to do that i'd need control over the html (i.e. using
bind not xml literals) and also serialisation. On that latter note,
what would you say to serialising the wizard as JSON? The key is not
to store the state of a particular wizard process for ABC user,
rather, to have the ability to persiste / load the right wizard based
on some dynamic choices elsewhere in the system. Perhaps provide a
trait that adds persistable abilities or something:
val myWizard = new Wizard with SerilizableWizard { .... }
Just throwing some ideas about :-)
Cheers, Tim
On Nov 7, 6:49 pm, Timothy Perrett <timo...@getintheloop.eu> wrote:
> Actually, just one other thing about this - sounds a bit like a
> workflow engine (to a degree its a specialised one) but JBoss Drools
> Flow has some interesting ideas in this area if your looking for some
> inspiration :-)
>
> Cheers, Tim
>
> On 7 Nov 2009, at 15:02, David Pollak wrote:
>
>
>
> > Basically, I'm separating the field logic/flow logic from any UI.
> > This will allow for automated testing of the wizards without a front
> > end (and if you trust the wizard state <-> UI translation, then
> > there's no need to test the stuff in a browser).
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
