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.

Hope that helps

Zope3-users mailing list

Reply via email to