On Tue, Nov 10, 2009 at 10:02 AM, Timothy Perrett <[email protected]>wrote:
> > 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. > I haven't refactored all the various ways of describing fields yet. I have to do a grand unification of these. > > - 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. > There is no use of mapper except for defining DB transactions. > > - 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 form generation is going to go through a lot of abstractions/factories that I didn't have time to write yesterday. I did the HTML piece in the last 30 minutes of coding. I spent most of the time getting the headless stuff working. > > - The next / prev / cancel / finish button elements should probably be > <input type="submit" value={...} /> > These will be part of the abstraction factory thing. > > - 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? Serialization in Scala generally sucks because serialization in Java sucks. Marius and I are working on ways to deal with it, but it's not likely to happen for 1.1. Wizard's state management is using the same patterns as generally Lift state management, so when we get all sorted out, Wizard will benefit... but until we can figure out how to reliably serialize functions, the problem is a very difficult one. > 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 <[email protected]> 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). > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
