cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Bols" <db...@osirion.be>
Subject RE: Woody - Determining the value for a widget
Date Sun, 23 Nov 2003 20:41:09 GMT
> 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.



> > > 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" and the xslt removes widgets by accident?

--
Danny


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message