On Fri, 2003-11-21 at 20:29, Danny Bols wrote: > > From: Bruno Dumon [mailto:[EMAIL PROTECTED]
<snipped use cases I resonate with/> > > > > The question is whether we should consider a missing request parameter > > > > (value == null) the same as an empty value (value = ""). Currently, > > > > they're considered to be equivalent and the field is > > therefore nullified. > > > > > > You are right, there is a big difference between a parameter > > which is not > > > available on the request and a parameter which has an empty > > value. So a +1 > > > for processing them differently and for not overriding widgets > > with unwanted > > > null values. > > > > It's more complicated then this. While this may work for the default > > renditions of the field widget (though I'm not sure the HTML spec > > requires empty fields to be submitted), it is for example impossible to > > do this for checkboxes. As suggested on the -dev ML a while ago, this > > could be solved by adding hidden id + ".present" fields to the form > > (though I don't like that very much from the HTTP-interface > > perspective). > > > > This would also allow to detect if a composite widget is not present, > > i.e. if a repeater is not present at all, none of its child widgets > > would need to be further processed. > > > > Anyway, I'm -1 for any solution that would only work for certain types > > of widgets. > > I agree with you. But the clue is NOT to use hidden fields! Why should we do > that? Since we have woody there is a form object which stores and cares > about al the form data. Just put only those fields in the template which > have to be editable during that particular step of the process. This is > about using the strengths of a FORM instance an not having to rely on a HTML > spec which was not really designed for this kind of interaction. > The basic principle is: ONE form object MULTIPLE templates/views. ok, got that. But how can we know, upon form submit, if a certain field was included in the request or not? This would indeed be possible if we knew what template was used in the publication pipeline. The template itself could however also be dynamic (i.e. generated by a JXTemplate). Another solution Torsten Curdt came up with is that the WoodyTemplateTransformer could collect the id's of all widgets that it effectively put on the form, and attach this information to the flowscript continuation object. What I don't like about this (otherwise very smart) approach is that it is very thightly bound to the continuations concept. However, it would be quite easy to let the WoodyTemplateTransformer embed a hidden field (or something that is translated to a hidden field by the XSLT) in the form containing this list of widget id's (this would be done right before encountering the closing wt:form-template tag). So then we'd only need one hidden field, and it wouldn't be the responsibility of the XSLT to create them. This could be made optional so that if there isn't such a hidden field, the behaviour is as it is now. > > > > Now this is debatable, furthermore considering that I envisioned to > > > > distinguish these two cases to raise an exception when a null-valued > > > > required field is not present on the request (see > > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24180). > > > > > > The case discussed in here is about giving a form-designer a > > test tool for > > > static (=simple?) forms (template wt: is equal to design wd:). I hope we > > > will not block the way for more dynamic templates / interaction. > > > > > > What do you think? > > > > I've got some more thinking to do on all this, but unfortunately my time > > to spend on this is quite limitted. But don't hesitate to share any > > further ideas on this. > > Great to hear your comments! Petty of your time to spent though :-( > I am willing to share a bit of my valuable time on this when needed. Great. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
