> -----Original Message----- > From: Bruno Dumon [mailto:[EMAIL PROTECTED] > Sent: zondag 23 november 2003 22:12 > To: [EMAIL PROTECTED] > Subject: RE: Woody - Determining the value for a widget > > > 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.
I don't know if the checkbox is the only stranger in town. A few other thoughts that came up to me: - Isn't using the ".present" trick less secure? It is possible to manipulate(or even hack) ".present" fields in the request string. OTOH it could also be a feature which gives the client the possibility to tell woody which fields are present and which are not. - I don't like the fact that we are leaning upon the HTTP spec for this solution. > > > > > 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? A "secure" form imo was a form in which woody should check all the request parameters against the widgets transformed by the WoodyTemplateTransformer. I was thinking to have this configurable. > > and the xslt removes widgets by accident? > > that's a bug in the XSLT then. Yep it would indeed be a bug......but it would be nice in that case if woody would raise an exception so the developper knows about it. -- Danny --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
