thanks a lot for your enlightments. > * the form can't know which widgets the template would decide to > display [and thus which widgets are the 'submitted widgets'], unless we > would encode that information in the request (ie. by adding a hidden > input field for each widget to indicate if it is there) >
I thought that the widget's existence (in the template) was tied to its presence in the request. Am I wrong ? > * but: it should be the server-side form model which expects certain > widgets to be there, instead of the other way around (ie the request > saying which widgets it decides to submit) > > * validation can do checks between multiple widgets, how should this > deal with the possibility of arbitrary widgets not being displayed? > template error msg: missing widget for validation (in this case it's a conceptual error) ? > * what to do with required widgets? Is it because the template author > decides that a widget should not be displayed, that is suddenly becomes > not required? > I know we are in the SOC world, but i don't separate the widget model role and the widget template role, because i think that the real "templatification" work is done throught the forms-styling.xsl stylesheet (not throught the forms transformer). IMHO forms-styling.xsl is the sole way to achieve consistency among the forms' displays. > * In general, I don't think it is the template writer who decides which > widgets to display. There's been suggestions about how one form model > should be combinable with multiple templates which display different > subsets of the widgets, but this doesn't make sense to me. Having one > form model for each separate form makes things much easier. Besides, > it's not like the template author could simply decide to move one widget > from one page to another, since the controller logic (and also the form > model with its validation logic) have expectations about widgets > actually being there on a page. As an example, take the amazon checkout > wizard: I don't believe it would be possible to randomly move widgets > between its different pages. > You could have some possible subsets and some impossible ones (which trigger conceptual errors). In our project we wanted to use Form as an abstract object which can encapsulate data access (through the binding framework), by which we can manipulate datas, and which can display themselves on demand. Our main multipage form bind to the whole customer structure (xindice access). One form.load(), several form.show()/form.save(), one save to the repository once the whole procedure is finished, and a cleaner logic between form's steps (all the submitted data are always accessible). > The solution lies, I think, in the union widget (which we still need to > finish up -- I don't know its current state). You can think of it as a > switch between multiple (groups of) widgets. You could then define a > union between "the widget" and "no widget", and switch the union to the > desired case. > Perhaps we can talk about models' view (and fill the gap between the template and the model roles) ? > Another solution may be the proposed widget states (see somewhere on the > wiki), though I don't have that fresh in my mind right now. > Thanks for the links, i'll wheck that. cheers.
