cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Bols" <>
Subject RE: Woody - Determining the value for a widget
Date Sat, 22 Nov 2003 07:11:30 GMT
> From: Timothy Larson []
> Sent: vrijdag 21 november 2003 21:02
> To:
> Subject: RE: Woody - Determining the value for a widget
> If we want to only send selected fields to the browser, and not
> all empty fields are guarantied to be sent back by the browser,
> then it seem we need to know which selected fields were sent so
> we will know which selected fields to process on return.
What to you want to achieve with this? What would you do when some fields
are missing on the request? Overwrite the form values with null values (and
destroy critical data in the form object like woody does now?)....or produce
an exception? You never have any guarantee on what is being send back by the
browser and even if all the fields being send back are the ones you expected
you don't have any guarantee over the values.
What I am trying to make clear is that we shouldn't overcomplicate the
architecture and the form processing. IMHO we should only process those
fields which are available on the request.

> To me this says we should either create explicit views of a form
> (to exist between the form definition and the form templates),
> or we need to collect (and possibly cache) the list of widgets
> that are in the template and use this list to drive the form's
> readFromRequest method.

We shouldn't overcomplicate the architecture. To get a form up and running I
already have 5 files to maintain... the definition, the template, the
sitemap and the flow script! Introducing views would make it 6.

> So far, I lean toward using an *optional* set of explicit views.
> This may even lead to the possibility of the view introducing
> view-specific widgets, driven by the same general set of needs
> that produced the aggregate widget.

I am not convinced about introducing views (see comments above). I could
imagine introducing an optional configurable transformer option though which
checks the fields being send back.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message