Dynamic form building powered by XML

[Tim Perrett]

Guys,

Just been noodling a few things and one of them was how to create a
process (kind of like Step 1, Step 2 etc) that can be variable? Some
times I might have 2 steps, other times X number of steps. System
wise, my thought was to have some kind of XML data-source that would
possibly look something like this:

<steps>
<step id="1">
<field name="First Name" control="text" />
<field name="country" control="dropdown">
<items>
<item>UK</item>
<item>France</item>
</items>
</field>
</step>
...
</steps>

Scala has pretty good XML support of course, so handling this type of
file would not be a problem. However, in terms of how to make the form
processing work etc, my thought was possibly to have some kind of
snippet and html fragment combo that had x functionally and the html
was the view for that component.

However, I guess im just after some good information on exactly how
lifts processing pipeline works so it would be possible to plumb
something like this back in? I know there are several issues with
dynamic snippet invocation (returning snippet html that need
subsequent processing/invocation from another snippet).

Any thoughts / advice at all would be great. If people think this is a
crap idea or there is a more lift way of achieving this functionality
then I would really love to hear it :-)

Cheers

Tim

[David Pollak]

You mean something like:
https://www.lostlake.org/wizard.wmv

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

[Tim Perrett]

Yeah sure - thats the kind of functionality im after. Perhaps not
quite so involved with java in xml, but sure, the variable screens and
validations are what i'm trying to achieve for sure.

Am I crazy / re-inventing the wheel to want to do something like this
with lift?

Cheers

Tim

On Sep 17, 6:06 pm, "David Pollak" <feeder.of.the.be...@gmail.com>
wrote:

[David Pollak]

Tim Perrett wrote:

Yeah sure - thats the kind of functionality im after. Perhaps not
quite so involved with java in xml, but sure, the variable screens and
validations are what i'm trying to achieve for sure.

Am I crazy / re-inventing the wheel to want to do something like this
with lift?
  

I was one of the folks who designed and built SmartMode back in 2000/2001.  SiteMap in Lift is substantially what we built in SmartMode (but in SmartMode, we needed XML files rather than a DSL.)

I've got a to-do hanging out to do Wizard as a Scala DSL in Lift... but I've got some documentation to write first. :-)

[Tim Perrett]

> I was one of the folks who designed and built SmartMode back in
> 2000/2001.  SiteMap in Lift is substantially what we built in SmartMode
> (but in SmartMode, we needed XML files rather than a DSL.)

Wow, awesome. SiteMap is easily the dark horse of lift :-)

When you say "SiteMap in Lift is substantially what we built in
SmartMode", are you talking conceptually, or functionally? If
functionally, then wow, seriously wow. Very cool. I'll dig into the
lift source to take a look at SiteMap tonight.....

> I've got a to-do hanging out to do Wizard as a Scala DSL in Lift... but
> I've got some documentation to write first. :-)

I would be seriously keen to work on this. If you can provide a
starting point or tips on where / how this might work I would happily
put all my "lift time" into making this work. Im also doing some cool
lift coding at work now, and this is something we'd really like so
could possibly commit some work days too.

Cheers

Tim

[David Pollak]

On Wed, Sep 17, 2008 at 11:14 AM, Tim Perrett <he...@timperrett.com> wrote:

> I was one of the folks who designed and built SmartMode back in
> 2000/2001.  SiteMap in Lift is substantially what we built in SmartMode
> (but in SmartMode, we needed XML files rather than a DSL.)

Wow, awesome. SiteMap is easily the dark horse of lift :-)

When you say "SiteMap in Lift is substantially what we built in
SmartMode", are you talking conceptually, or functionally? If
functionally, then wow, seriously wow. Very cool. I'll dig into the
lift source to take a look at SiteMap tonight.....

Both conceptually and functionally.  SiteMap in SmartMode was more brittle than SiteMap in Lift.  There are a few missing features from SmartMode SiteMap in Lift's implementation, but for the most part, it's stuff that wasn't used for the SmartMode powered sites.
 

> I've got a to-do hanging out to do Wizard as a Scala DSL in Lift... but
> I've got some documentation to write first. :-)

I would be seriously keen to work on this. If you can provide a
starting point or tips on where / how this might work I would happily
put all my "lift time" into making this work. Im also doing some cool
lift coding at work now, and this is something we'd really like so
could possibly commit some work days too.

I am enclosing the XML file that defined the Wizard XML.  Maybe you can start modeling the DSL grammar based on the tags in Wizard.

Thanks,

David

 

Cheers

Tim

[Tim Perrett]

> Both conceptually and functionally.  SiteMap in SmartMode was more brittle
> than SiteMap in Lift.  There are a few missing features from SmartMode
> SiteMap in Lift's implementation, but for the most part, it's stuff that
> wasn't used for the SmartMode powered sites.

Interesting - can you elaborate on lifts flexibility over SmartMode?
It would be interesting to hear the comparison

> I am enclosing the XML file that defined the Wizard XML.  Maybe you can
> start modeling the DSL grammar based on the tags in Wizard.

Ok I will do :)

Would I be correct in assuming that SiteMap gives you the flexibility
of display what and when conditionally, but as each form is being
generated dynamically, how would you commit back after each step - or
is it a case that all that data is held in state somehow and then it
just spits it out at the end to which you do what ever need be with
it? And if thats the case, how would it do that? Many objects, or one
massive lump of data etc?

Also, the stuff thats going to be broken away from mapper,
specifically the validation stuff - would you see that as being
reusable in this context?

Sorry for the barrage of questions - I just find this fascinating!

Cheers

Tim

[David Pollak]

On Wed, Sep 17, 2008 at 4:14 PM, Tim Perrett <he...@timperrett.com> wrote:

> Both conceptually and functionally.  SiteMap in SmartMode was more brittle
> than SiteMap in Lift.  There are a few missing features from SmartMode
> SiteMap in Lift's implementation, but for the most part, it's stuff that
> wasn't used for the SmartMode powered sites.

Interesting - can you elaborate on lifts flexibility over SmartMode?
It would be interesting to hear the comparison

Over a beer, yes.  :-)
 

> I am enclosing the XML file that defined the Wizard XML.  Maybe you can
> start modeling the DSL grammar based on the tags in Wizard.

Ok I will do :)

Would I be correct in assuming that SiteMap gives you the flexibility
of display what and when conditionally, but as each form is being
generated dynamically, how would you commit back after each step - or
is it a case that all that data is held in state somehow and then it
just spits it out at the end to which you do what ever need be with
it? And if thats the case, how would it do that? Many objects, or one
massive lump of data etc?

Each page in Wizard will have a call-back function and on success (at the very end of the Wizard when one does the final 'okay'), all the functions will be called and working with Mapper, there'll be a single Database transaction for all the function calls.
 

Also, the stuff thats going to be broken away from mapper,
specifically the validation stuff - would you see that as being
reusable in this context?

Yes.
 

Sorry for the barrage of questions - I just find this fascinating!

:-)
 

Cheers

Tim

[Tim Perrett]

> Over a beer, yes. :-)

Until they invent virtual beer, how's about IM?

> Each page in Wizard will have a call-back function and on success
> (at the very end of the Wizard when one does the final 'okay'), all
> the functions will be called and working with Mapper, there'll be a
> single Database transaction for all the function calls.

Given all the attention JPA is getting, that says to me that we would
need a solution that was persistence agnostic as much as possible.
This will obviously make it a lot tricker, but I think its really
important as the people who generally want this functionality, are
more "enterprisy" and are usually using stuff like Hibernate or
TopLink etc

> Yes.

Thought as much.

Cheers

Tim

[David Pollak]

On Wed, Sep 17, 2008 at 4:49 PM, Tim Perrett <he...@timperrett.com> wrote:

> Over a beer, yes.  :-)

Until they invent virtual beer, how's about IM?

It's a time thing.  Spending 30-60 minutes comparing pieces of Lift to the long-dead SmartMode is not high on my priority list... sorry.
 

> Each page in Wizard will have a call-back function and on success
> (at the very end of the Wizard when one does the final 'okay'), all
> the functions will be called and working with Mapper, there'll be a
> single Database transaction for all the function calls.

Given all the attention JPA is getting, that says to me that we would
need a solution that was persistence agnostic as much as possible.
This will obviously make it a lot tricker, but I think its really
important as the people who generally want this functionality, are
more "enterprisy" and are usually using stuff like Hibernate or
TopLink etc

Like what we've done with LiftRules, there'll be default behavior that can easily be over-ridden.
 

> Yes.

Thought as much.

Cheers

Tim

[Tim Perrett]

Ok been noodling this - what bout something like:

object Wizard extends LiftWizard {
val someGlobalVar: String = "something"

object ScreenOne = new WizarScreen({
var firstName = TextField(value, FieldType.STRING, {
// validation rules go here
})
var lastName = TextField(value, FieldType.STRING, {
// validation rules go here
})
})

object ScreenTwo = new WizarScreen({
var aggreeTerms = Checkbox(onvalue, offvalue, FieldType.BOOL, {
// validation rules go here
})
})

def save = {
// some databsae writing or whatever
}

}


I didnt include the validation stuff as I thought that would be
transfered from what ever the record/field stuff ends up looking like
when its broken out from Mapper.

Thoughts?

Tim