From: Torsten Curdt > Reinhard Poetz wrote: > > > 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 ;)
I hope many other follow us! Beside blocks Cocoon forms is the next big thing! Whenever I talk about Cocoon I nearly always get questions on form handling ... > > <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 Bruno, what do you think? > > > 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" ;) sorry for this :-( > > > 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 yes, that's definitly the responsibility of the flow > - which makes a > general definition of a multipage form quite complicated. currently it is difficult because when the form is validated *all* widgets of the widget definition file are needed. if we remove this restriction and use the instantiated widgets it should become easier ... > > On the other hand the result of a multipage form is quite > often needed as a single form instance. this makes the writing of flow applications easier and less ugly (otherwise you would have to do the load/save for every page and at the end you have to take care that you don't persist e.g. your bean if there is a problem > 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... Sylvain suggested to introduce variables that are bound to a continuation. If we add the list off all widgets which have to be validated we'll have the first use case ;-) Are there any other thoughts on this? > > <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) did we have the same customer? ;-) Reinhard
