Sending data to widgets

[Frank Burkhardt-2]

Hi,

I need to send some data from a view class to all widgets that are
used in the form. Unfortunately some of the widget that need to receive those
data are contained e.g. in lists or dictionaries.

I tried to do somthing like this:

 request._data=somedata

My view class would add 'somedata' to the request and all the widget would be able
to use it.

But the the BrowserRequest doesn't like to be modified. It there a chance to
transport data throught the request object without modifying the depth
of the zope core?

Maybe there's a way for widgets to access the view class directly?

Regards,

Frank
_______________________________________________
Zope3-users mailing list
Zope3-users@...
http://mail.zope.org/mailman/listinfo/zope3-users

[Philipp von Weitershausen]

Hi Frank,

> I need to send some data from a view class to all widgets that are
> used in the form. Unfortunately some of the widget that need to receive those
> data are contained e.g. in lists or dictionaries.
>
> I tried to do somthing like this:
>
>  request._data=somedata
>
> My view class would add 'somedata' to the request and all the widget would be able
> to use it.
>
> But the the BrowserRequest doesn't like to be modified.

Right. Requests are read-only to the application.

> It there a chance to transport data throught the request object
> without modifying the depth of the zope core?
>
> Maybe there's a way for widgets to access the view class directly?

A typical solution is to push data to the widgets. IWidget (from
zope.app.form.interfaces) defines a 'setRenderedValue' method for
widgets that can be used to do that.

If you are using zope.formlib, you can also implement a custom
setUpWidgets method (documented in IFormBaseCustomization from
zope.formlib.interfaces). The default one for edit forms looks like this:

    def setUpWidgets(self, ignore_request=False):
        self.adapters = {}
        self.widgets = setUpEditWidgets(
            self.form_fields, self.prefix, self.context, self.request,
            adapters=self.adapters, ignore_request=ignore_request
            )

setUpEditWidgets (defined in zope.formlib.form) will take the widget's
default values from self.context. For example, you could pass in
something other than that (perhaps an object holding the data you want
the widgets to present). You just have to make sure that it also
provides the interface that you're generating the form from.

Philipp

_______________________________________________
Zope3-users mailing list
Zope3-users@...
http://mail.zope.org/mailman/listinfo/zope3-users

[Frank Burkhardt-2]

Hi,

On Tue, Apr 18, 2006 at 03:20:49PM +0200, Philipp von Weitershausen wrote:

[snip]

> Right. Requests are read-only to the application.
>
> > It there a chance to transport data throught the request object
> > without modifying the depth of the zope core?
> >
> > Maybe there's a way for widgets to access the view class directly?
>
> A typical solution is to push data to the widgets. IWidget (from
> zope.app.form.interfaces) defines a 'setRenderedValue' method for
> widgets that can be used to do that.
>
> If you are using zope.formlib, you can also implement a custom
> setUpWidgets method (documented in IFormBaseCustomization from
> zope.formlib.interfaces). The default one for edit forms looks like this:
>
>     def setUpWidgets(self, ignore_request=False):
>         self.adapters = {}
>         self.widgets = setUpEditWidgets(
>             self.form_fields, self.prefix, self.context, self.request,
>             adapters=self.adapters, ignore_request=ignore_request
>             )
>
> setUpEditWidgets (defined in zope.formlib.form) will take the widget's
> default values from self.context. For example, you could pass in
> something other than that (perhaps an object holding the data you want
> the widgets to present). You just have to make sure that it also
> provides the interface that you're generating the form from.

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?

Regards,

Frank
_______________________________________________
Zope3-users mailing list
Zope3-users@...
http://mail.zope.org/mailman/listinfo/zope3-users

[Philipp von Weitershausen]

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

Philipp
_______________________________________________
Zope3-users mailing list
Zope3-users@...
http://mail.zope.org/mailman/listinfo/zope3-users

[Frank Burkhardt-2]

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
_______________________________________________
Zope3-users mailing list
Zope3-users@...
http://mail.zope.org/mailman/listinfo/zope3-users

[Gary Poster-2]

On Apr 18, 2006, at 10:19 AM, Frank Burkhardt wrote:

> 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.

augh! :-)

Philipp is leading you correctly.  I might even be tempted to write a  
custom form that directly set the data for the widgets myself; maybe  
that would be a quicker and easier approach to the same road.

If you still don't want to listen to him, please don't do the  
response hack you are talking about.  the request has an  
`annotations` attribute which experts can use to stash things away.  
Beware: this is a road that has bitten many in Zope 2, and is easily  
abused.

Gary


_______________________________________________
Zope3-users mailing list
Zope3-users@...
http://mail.zope.org/mailman/listinfo/zope3-users

[Frank Burkhardt-2]

On Tue, Apr 18, 2006 at 10:28:38AM -0400, Gary Poster wrote:

[snip]

> >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.
>
> augh! :-)
>
> Philipp is leading you correctly.  I might even be tempted to write a
> custom form that directly set the data for the widgets myself; maybe that
> would be a quicker and easier approach to the same road.

That's what I did. I used formlib to create widgets, added an attribute
containing the information I needed to send from the view to the widgets.

It worked like a charm - until I used some more complex data structures
(Lists, Dicts). I don't know a way of adding attributes to the subwidgets
of e.g. ListWidgets because those subwidgets are created on the fly during
the ListWidgets' rendering/query-parsing process.

Works:

 IMyObject
 +-i18ntext

Doesn't work:

 IMyNewObject
 +-List of...
 | +-i18ntext
 +-Dict of...
   +-(BytesLine,i18ntext)

> If you still don't want to listen to him, please don't do the response
> hack you are talking about.  the request has an `annotations` attribute
> which experts can use to stash things away.  Beware: this is a road that
> has bitten many in Zope 2, and is easily abused.

I would really like always to use the Zope(tm) way. I'll try the annotations
attribute (although I'm not really an expert :-) ).

Thank you,

Frank
_______________________________________________
Zope3-users mailing list
Zope3-users@...
http://mail.zope.org/mailman/listinfo/zope3-users