On Sun, 2003-11-23 at 21:41, Danny Bols wrote: > > From: Bruno Dumon [mailto:[EMAIL PROTECTED] > > Sent: zaterdag 22 november 2003 16:48 > > To: [EMAIL PROTECTED] > > Subject: RE: Woody - Determining the value for a widget > > > > > > On Sat, 2003-11-22 at 08:41, Danny Bols wrote: > > > > From: Bruno Dumon [mailto:[EMAIL PROTECTED] > > > > Sent: vrijdag 21 november 2003 21:10 > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: Woody - Determining the value for a widget > > > > > > > > > > > > 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). > > > > > > I agree...we don't know which fields should be inculded in the > > request. But > > > does woody know this at this moment? I don't think so, woody > > acts as if all > > > the widgets should be availble by overwriting them with null > > values if they > > > aren't available. So IMHO the current version of woody doesn't have a > > > solution for this either > > > > As said before in this thread, Woody doesn't support this indeed, > > otherwise this thread wouldn't be here in the first place :-) > > > Making a solid solution for this is very complicated: how would woody > > > possibly know which fields should be available on the request? > > And what do > > > we get for it in return? .... still no guarantee on the values > > of the fields > > > on the request. I think we should be very pragmatical and not > > overcomplicate > > > processing and lose flexibility. > > > > But what's your solution then? It is not because there's no request > > parameter, that there's no widget. OK, this might be true for a field > > widget rendered as an <input> box, but it's not the case for checkboxes > > (unchecked checkboxes do not give a request parameter). All I'm asking > > for is a solution that will work for all types of widgets. If it's only > > the checkbox which has this problem then maybe we could only use the > > ".present" trick for widgets that can be rendered as checkboxes. > > The nice thing about the ".present" trick is that it also would work without > the use of continuations. On the other hand I like the solution of Torsten > to collect all the id's of the widgets in the WoodyTemplateTransformer and > to put them in the continuation object which is a much cleaner approach. > So a +1 for the Torsten approach now the relationship between woody and flow > is becoming much closer.
I don't mind using the continuation for this purpose, but there should be an alternative for in case continuations are not available. But to repeat myself: if it's only the checkbox that has this 'problem', I'd go for the .present trick. > > > > 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. > > > > > > And what if my xslt skips certain fields based on their styling > > attributes? > > > > That would not be allowed. The role of the XSLT is to style widgets, not > > to remove them. > > OK. What do you think woody should do in case a form is configured as > "secure" What do you mean? > and the xslt removes widgets by accident? that's a bug in the XSLT then. -- 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]
