[Zope3-dev] Proposal for more widgets cleanup

[Janko Hauser]

Garrett Smith wrote:
> Janko Hauser wrote:
>
>>Garrett Smith wrote:
>>
>>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.
>
Ah, understood, so one would first generate a specialized skin, and then
use therein references to special macros if needed. To the second, we
use currently not the form machinerie so I haven't realized this right
away.

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

>
>>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.
>
Yeah, this second approach was mentioned at other places and I think I
have it understood now. But I haven't seen an example yet. What's
missing in my mental view, is how to keep the number of schemas low. I
think of an initial schema with ten fields, and I only want to overwrite
one in a special context. I do not want to replicate the complete
schema, perhaps this could be reduced by subclassing the original one.

But how do I connect the new schema with the existing content object?
Especially in ZCML? And do I need to define Attribute-fields for the
fields the adapted schema provides. My goal is, to have the
contentobjekt fully described by schema, so that I can export and import
it into the system.

I hope my questions are not convoluted. Is there somewhere a code
example for the second approach, so I can try to wrap my ahead around
this?

no matter what, thanks Garrett for steering me into the right direction.

__Janko