[Zope3-Users] Re: Sending data to widgets

[Frank Burkhardt]

Hi,

On Tue, Apr 18, 2006 at 04:04:43PM +0200, Philipp von Weitershausen wrote:
> Hi Frank,
> 
> > My problem is not about data the widget should display but about data
> > that controls the widget's behaviour.
> > 
> > In this case my form consists of some widgets representing a schema interface
> > plus a special "I18NController" widget which is e.g. used to define, in which
> > order different language versions of the form's fields should be displayed.
> > (->This is about I18Nd content, stored in dictionary-fields)
> > 
> > Problem is: Some of the Widgets that should receive data from the "I18NController"
> > are not known to the formlib because they are multiadapter-queried inside e.g.
> > a ListInputWidget. The request + the context seem to be the only objects accessible
> > to all the widgets - but I don't want to store language order information in zodb which
> > leaves the request object only.
> > 
> > Is there really no chance to store information as attributes of the request?
> 
> Perhaps there is, but I would still advise against it.
> 
> In this case I would recommend to make use of the adaption feature of
> zope.formlib. The "context" of the form and widgets doesn't necessarily
> have to be the persistent object itself. It can be an adapter. That way
> you can generate schema-based forms using schemas that aren't even
> provided by the object you're editing. zope.formlib will automatically
> adapt the object to the schema. The adapter will be responsible for
> mediating between formlib and the object.
> 
> An example is the Metadata tab in the ZMI. The schema is something like
> IZopeDublinCore (at least some Dublin Core metadata), though no object
> really provides this data. However, there's an adapter that the data can
> be written to and that knows how to modify the object accordingly.
> 
> In your case your adapter would probably behave like the original
> "context" except that it also stores this i18n ordering that you don't
> want to be stored persistently but still need for the form.

Perhaps it's overkill to write adapter for all my content objects. I think
I found a solution. The Request object might be RO but I can smuggle an object
reference inside the reponse headers and removed it after all the widgets are
processed.

Thank you,

Frank