After (nearly) finishing a project where we implemented our own little forms frameworks (... we had already started when Woody became part of Cocoon) I want to share some ideas with you.
..another one ;)
<snip/
The global widget repository contains widgets that can be reused in all forms within your Cocoon installation. I also think that it could be possible to extend global widget defintions:
<wd:field id="glEmail" required="true"> <wd:datatype base="string"> <wd:validation> <wd:email/> </wd:validation> </wd:datatype> </wd:field>
<wd:field id="supplierEmail" extends="glEmail"> <wd:label>Supplier's email address:</wd:label> </wd:field>
<wd:field id="customerEmail" extends="glEmail"> <wd:label>Customer's email address:</wd:label> </wd:field>
I think this sounds like a good idea
We have already discussed this several times on the dev-list and at the GetTogether in Gent. IIUC Thorsten, Bruno and I agreed that we don't
please note: Torsten - no "h" ;)
like some kind of a "phases" concept because everything you need can be found at the template and why should you declare things twice. If you think of dynamic forms (e.g. wheter a widget is show depends on the rights of the user) you also come into troubles because your phases will have to become dynamic too!
yes, we are on the same page here. phases are bad from a SOC point of view.
As mentioned the list of the required widgets is already known because the template transformer instantiates all widgets. But there is a problem (or at least I'm not sure how to solve it) with this approach: The template transformer is the last step before a new continuation is created. So it would be possible to save a list of all required widgets. That's fine. The problem is that this list has to be connected to a certain continuation because otherwise you would get serious troubles if the user clones the window. OTOH if we save the list of the required widgets with the continuation it can become expensive from a memory POV, can't it?
hm... hard to say... it would definitly increase the size of a continuation quite a bit!
Are there other thougts how to solve the multi page forms problem? Sylvain, you mentioned at the end of your presentation something at the
GT Hackaton but I can't remember. Could you help us (me)?
Sylvain has made a valid point at the GT. The flow might want to decide which form is to be shown next - which makes a general definition of a multipage form quite complicated.
On the other hand the result of a multipage form is quite often needed as a single form instance. So *if* we split a multipage forms into different individual forms we would need an easy way to aggregate the data again.
But I don't really have a clue here yet...
<snip/>
* You don't need to load such a long list like all countries
in the world at form load time but then when the user
wants to fill in the value
(this makes no real difference for one field but if you have e.g.
10 fields containing so many possible values there is one, believe
me!)
sounds like a good idea! (I feel your pain ;) one of our customers insisted to have a dropdrown list of up to 300 entries) -- Torsten
