lift-wizard progress?

[Timothy Perrett]

Guys,

I've noticed that the lift-wizard hasn't had any commits for ages -
where is this too in terms of usability etc?

I was looking at the implementation and was wondering if wizard
serialisation had been considered? I would use the wizard code as soon
as it was available and serialisation would be a really important
feature for us - that is, the ability to serialise a wizard process,
persist it, and reload it on-demand at a later date... its highly
likely that we would have several wizard type processes to load
dynamically from disk / datastore etc.

Cheers, Tim

[David Pollak]

On Fri, Nov 6, 2009 at 3:55 PM, Timothy Perrett <tim...@getintheloop.eu> wrote:

Guys,

I've noticed that the lift-wizard hasn't had any commits for ages -
where is this too in terms of usability etc?

I'm presenting it at Bay Area Scala Enthusiasts on Monday... although I've written almost no new code... but I have a killer design in my head.  Expect something working and marginally usable on Monday night (just before I leave for LinkedIn).

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).
 

I was looking at the implementation and was wondering if wizard
serialisation had been considered?

Interesting feature.  It brings up the whole serialization issue.  Marius and I were chatting about that on Friday.  Maybe it'll be my mission post M8 to get serialization nailed.
 

I would use the wizard code as soon
as it was available and serialisation would be a really important
feature for us - that is, the ability to serialise a wizard process,
persist it, and reload it on-demand at a later date... its highly
likely that we would have several wizard type processes to load
dynamically from disk / datastore etc.

Cheers, Tim

--
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

[Timothy Perrett]

On Nov 7, 3:02 pm, David Pollak <feeder.of.the.be...@gmail.com> 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).

Sounds interesting - looking fwd to seeing it.

> Interesting feature.  It brings up the whole serialization issue.  Marius
> and I were chatting about that on Friday.  Maybe it'll be my mission post M8
> to get serialization nailed.

ok sounds interesting - i'll keep an eye on the repo until monday
then!

Cheers, Tim

[Timothy Perrett]

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

[Timothy Perrett]

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

[David Pollak]

On Tue, Nov 10, 2009 at 10:02 AM, Timothy Perrett <tim...@getintheloop.eu> 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 <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).

[Timothy Perrett]

Hey Dave,

> I haven't refactored all the various ways of describing fields yet.  I have
> to do a grand unification of these.

Yeah - this would be super; I think as we move forward this is going
to be really important.

> There is no use of mapper except for defining DB transactions.

Oh I see - hmm. Is there a way we can leverage the lift-jta monad
instead? Again, not that its a feature id probably use, but just
thinking about ways to keep it all persistence agnostic. If not lift-
jta, then perhaps some broader transaction semantic in record. Food
for thought at least :-)

> 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.

haha - awesome. Thought that might be the case.

> > - The next / prev / cancel / finish button elements should probably be
> > <input type="submit" value={...} />
>
> These will be part of the abstraction factory thing.

Super.

> 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.

Ah. Bummer - completely forgot about this. Just a suggestion but it
might be worth a conversation with Jonas - he's been working of some
pretty heavy serialisation stuff in Akka so maybe it could spark some
ideas for yourself / marius with this particular problem.

Cheers, Tim

PS: I do genuinely think this is great stuff - i don't mean to moan,
im just really keen to have a play with this stuff and wield it to
solve my problems in a particular app :-)