cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject RE: Woody - Determining the value for a widget
Date Sun, 23 Nov 2003 21:12:06 GMT
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]
> > > >
> > > > <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
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


Mime
View raw message