On Sun, 2004-05-30 at 15:01, BURGHARD Eric wrote: > 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 ?
It's not true in all cases: * complex widgets that translate to multiple HTML controls, eg a repeater: how can we know it's there? * HTML checkboxes don't add a request parameter when unchecked But let us reason a bit further: suppose that we know of each widget if it was submitted during the current form processing cycle. The validation logic would then run over the widget tree and only validate the widgets marked as 'freshly submitted'. But what would be the value of the outcome of this partial validation? If the outcome is 'false', we know we need to redisplay the form. If the outcome is 'true', we don't know what state the form is in, because the 'true' only tells something about the freshly submitted widgets, not about the form as a whole. From another point of view: it would be the client who decides what to validate and what not. > > > * 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, me neither > 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. ok. But don't forget that the "form model" is just that: the model of the form. It shouldn't replace the application/backend model (which might simply be a DOM-tree in your case). > 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, needing to have a few extra lines for multiple form.load()s and form.save()s doesn't seem to be such a huge problem? > and a cleaner logic between form's > steps (all the submitted data are always accessible). accessible by who / from where? > > > 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) ? The basic idea was to have no distinction between the form model and the form view, they correspond one-to-one to each other. While it might be possible to separate those two concepts, I'm not really convinced about it just yet. > > > 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. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
