[Zope3-dev] Proposal for more widgets cleanup

[Garrett Smith]

Janko Hauser wrote:
> Garrett Smith wrote:
>> This proposal deals with some rough edges associated with the way
>> widgets handle errors. If you haven't written any of your own
>> widgets, it should not impact your code.
>> 
>> The proposal incorporates input from Marius Gedminas and Jim.
>> 
>>   http://dev.zope.org/Zope3/MoreCleanupOfWidgets
>> 
> 
> Some questions, perhaps not all directly related to the proposal. It
> can be, that I do not use widgets totally right or to the full extent.
> 
> +1 to all points regarding the change of the error handling.
> 
> to point 8:
> Doesn't the collection of the html rendering in one macro file make it
> harder to overwrite stuff? Can this be changed in ZCML and/or
> programmatically. For example the widget could decide to render itself
> differently in case of some special error.

The advantage of the page template macro is that it lets you control the
label, widget, and error rendering per skin, but not per error type.

As for displaying errors based on their type, you could provide your own
widget_macros template that looked up a view to an error:

  <tal:block repeat="error widget/errors">
    <tal:block content="structure error/@@some_view" />
  </tal:block>

> I understand widgets as some kind of viewclass_method, which processes
> the information and then delegates to a template for rendering. Is
> this possible with the current approach?

The gist of the final approach is that widgets a) directly implement the
UI of the widget itself (e.g. the text field, radio button, etc.) and b)
provide additional information related to the widget that a form would
be interested in displaying (e.g. labels, tooltips, errors). The form is
responsible for displaying the 'part-b' information, generally by way of
pate template macros.

> to point 9:
> It looks funny to set the error twice. Where is the widget errors list
> to be used? Is it during the rendering of the InputWidget in the
> returned form? Then why set it in self again.

The form's errors list is a convenience to the page template, since it's
common to display error summary information at the top of the form. It
would unnecessarily complicate the page template to omit it.

> Then not directly related to the proposal:
> 
> There are many cases, where a field does need different widgets, or a
> widget, which handles some cases different. Also fields are changing
> their configured state during their lifetime, and would need perhaps
> different widgets then. One example would be the readonly fields
> 'modified' and 'created'.
> 
> At the moment the widgets are differentiated between Input and
> Display, but it can be, that one widget is used to display a field
> readonly only in some situations, which are overall Input contexts.
> 
> Jim mentioned the example of adding something, where one would key
> something in, but which would be readonly afterwards. One can place
> these things in intelligent widgets, but these would be harder to
> replace. Are there other ways?
> 
> Or I would like to display the 'modified' data only readonly but
> clearly want to change the field in the normal application. But a
> manager should be allowed to change the last modified entry.

If I understand your point/question correctly, I'd say there are two
ways of handling your use cases. First, you can skin a new set of
widgets that implement your various display/edit policies as needed.
E.g. the widget (a view) could be a dispatcher that looked up other
widgets based on current user, security settings, time of day, whatever.

Second, and I do this a lot (and I'd say the prefered approach), you can
adapt an object for a specific schema, which would be used by the form
machinery to lookup field widgets. The adapter could even assemble a
schema on the fly, again, based on your various policies.

 -- Garrett