Return-Path: Delivered-To: apmail-cocoon-users-archive@www.apache.org Received: (qmail 62293 invoked from network); 23 Nov 2003 21:12:19 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 23 Nov 2003 21:12:19 -0000 Received: (qmail 94974 invoked by uid 500); 23 Nov 2003 21:11:59 -0000 Delivered-To: apmail-cocoon-users-archive@cocoon.apache.org Received: (qmail 94959 invoked by uid 500); 23 Nov 2003 21:11:59 -0000 Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: users@cocoon.apache.org Delivered-To: mailing list users@cocoon.apache.org Received: (qmail 94946 invoked from network); 23 Nov 2003 21:11:59 -0000 Received: from unknown (HELO astra.telenet-ops.be) (195.130.132.58) by daedalus.apache.org with SMTP; 23 Nov 2003 21:11:59 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by astra.telenet-ops.be (Postfix) with SMTP id 4162837FE8 for ; Sun, 23 Nov 2003 22:12:04 +0100 (MET) Received: from yum.ot (D5774E46.kabel.telenet.be [213.119.78.70]) by astra.telenet-ops.be (Postfix) with ESMTP id AFACA37FCC for ; Sun, 23 Nov 2003 22:12:03 +0100 (MET) Subject: RE: Woody - Determining the value for a widget From: Bruno Dumon To: users@cocoon.apache.org In-Reply-To: References: Content-Type: text/plain Organization: Outerthought Message-Id: <1069621926.17497.389.camel@yum.ot> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 23 Nov 2003 22:12:06 +0100 Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Sun, 2003-11-23 at 21:41, Danny Bols wrote: > > From: Bruno Dumon [mailto:bruno@outerthought.org] > > Sent: zaterdag 22 november 2003 16:48 > > To: users@cocoon.apache.org > > Subject: RE: Woody - Determining the value for a widget > > > > > > On Sat, 2003-11-22 at 08:41, Danny Bols wrote: > > > > From: Bruno Dumon [mailto:bruno@outerthought.org] > > > > Sent: vrijdag 21 november 2003 21:10 > > > > To: users@cocoon.apache.org > > > > Subject: RE: Woody - Determining the value for a widget > > > > > > > > > > > > On Fri, 2003-11-21 at 20:29, Danny Bols wrote: > > > > > > From: Bruno Dumon [mailto:bruno@outerthought.org] > > > > > > > > > > > > > > > > > > > > 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 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 bruno@outerthought.org bruno@apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org For additional commands, e-mail: users-help@cocoon.apache.org