[Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

[Gary Poster]

On Aug 29, 2005, at 4:24 PM, Garrett Smith wrote:

> To ease our own development, I forked the schema and widgets code a  
> while back. I don't think we've deviated too severely, but I've  
> added whatever 2 cents based on my experience below.
>
>
>> 1 Flesh out the 'source' design and implementation so it can replace
>> and deprecate vocabularies.  Specifically, to match the capabilities
>> of vocabularies, we'll add an interface that a source can implement
>> if they want to be bound to a context; and we will make it possible
>> to have iterable sources (for small collections as would be
>> appropriate for selections, radio button groups, checkbox groups,
>> etc.).  This will reduce the potential for confusion by letting
>> sources be the 'one true way' to describe possible options for a
>> choice, instead of the current overlap of vocabularies and sources.
>> The primary advantage to sources over vocabularies are that
>> the model
>> is cleaner; the only additional feature is the ability to configure
>> different tokens for a given source.
>>
>
> This sounds good. The one main hassle I've faced with vocabularies  
> is the seeming complexity of the queriables UI scheme. I've spent  
> much time tracking down how everything fits together, but  
> unfortunately never spent the time to figure out a simpler  
> approach. If it's already as simple as possible, fine -- sometimes  
> stuff's just hard to simplify.

It isn't the easiest thing to grok, no.  We don't have any ideas to  
improve it either, except to add more documentation, which is still  
lacking AFAIK.  Maybe writing more documentation will reveal other  
ideas...

>> 2 Clean up the exceptions widget framework.  The use of the widget
>> input error is quite messy: see collector issue 273.  The idea would
>> be to make the use of the errors argument more consistent and more
>> restricted, and make the 'doc' implementation simpler.
>>
>
> I have a ValidationError that looks like this:
>
> class ValidationError(zope.schema.interfaces.ValidationError):
>
>     def __init__(self, msg, *args):
>         zope.schema.interfaces.ValidationError.__init__(self, *args)
>         self.msg = msg
>
>     def doc(self):
>         return self.msg
>
> This was to workaround the strangeness of displaying a class-level  
> description, rather than the specific msg provided with the error.

Cool: yes, that's very, very similar to our internal one, except I  
have an optional mapping arg (for values to be placed in the  
i18n.Message) and no *args.

>> 3 Make the arbitrary constraints in the schema framework more
>> powerful: specifically, allow a field to accept more than one
>> constraint, and have the constraints raise errors (with an i18n doc,
>> if desired) rather than return an uninformative Boolean.
>> This can be
>> done in a backwards (and deprecation) compatible way by keeping the
>> constraint argument and adding a constraints argument wit the new
>> semantics; or with another approach. *would need small proposal*
>> *code exists*
>>
>> 4 Recognize and document that the 'default' field argument is
>> actually 'initial value'.  That is, if you set a field with a
>> default
>> to the missing_value, the default does not become the field's value:
>> the 'default' value is only used if the value has never been set
>> (i.e., during creation or when there is no previous state of the
>> value).  Possibly rename to 'initial_value' (with deprecation
>> support).  *would need proposal*
>>
>
> Our version of IField has an 'initial' attribute. We don't use  
> default. I prefer 'initial' to 'initial_value'.

That sounds good to me.  I don't feel strongly about "initial_value":  
short is good.

>> 5 Allow fields to accept a default (or initial_value, as above) *or*
>> a default_getter (or initial_value_getter, as above).
>> default_getter/
>> initial_value_getter would be a callable passed the field's
>> context.
>> It should return the desired initial value.  Use cases include
>> initializing to now, today, the current user, etc.  *would
>> need small
>> proposal* *code exists*
>>
>
> Couldn't 'initial_getter' just be implemented using a property  
> version of 'initial'?

Yes, it could.  The only downside is that it wouldn't be usable as an  
initialization argument.  I don't feel very strongly about it one way  
or the other.  It sounds like Jim is a definite -1 (as I thought he  
might be :-) so I'm happy to drop it.

>> 6 Add union field and widget to schema and form, respectively.  A
>> union field allows a user to fill in one of several types of
>> values.
>> Use cases include faux combo boxes (i.e., a choice or a text line),
>> date/duration choices, etc.  Widget is reasonable and has been used
>> by ZC for more than a year.  *would need small proposal* *code  
>> exists*
>>
>> 7 add combination field and widget to schema and form,
>> respectively.
>> A combination field allows a user to fill in multiple values
>> simultaneously, and returns a tuple of the combined values.  Use
>> cases overlap somewhat with object field/widget, but this is simpler
>> to use for simple use cases.  Use cases include range fields.
>>  *would
>> need small proposal* *code exists*
>
> Cool. I don't know if this is the same thing, but we have a widget  
> that handles editing two related fields. One field is a boolean  
> that, when False, renders the other field not-applicable. E.g. when  
> the user unselects a checkbox, a list box becomes disabled. Our  
> implementation is a bit of a hack, since the widget has to cheat  
> and get access to additional fields.

Huh, interesting.  It sounds different.  What is the typical use for  
this sort of field?

>> 8 Add suggestion and MRU (Most Recently Used) widgets.  These
>> widgets
>> provide a drop down of suggested (specifically most recently
>> used for
>> the MRU widget) values for a choice field.  They really make using
>> choice widgets much nicer in many cases.  *code exists* *proposal
>> needed for also adding another of our packages to the core, on which
>> this relies*
>>
>> 9 Add standard timezone source and widget.  *code exists* for
>> something that should really be a shared community effort.
>> Relies on
>> suggestion widget and MRU widget, above.
>>
>
> This would be super to have, consdering the proliferation of tzinfos.
>
>
>> 10 The big restructuring of schema: divide up schema into interface
>> values and usage relationships.  This is too big to explain in this
>> email, and probably too big to even adequately begin in two days.
>> This is the direction Jim wants to take schema, though, and I'm +1.
>>
>> 11 Brainstorm current state of the widget API and base classes and
>> start some significant cleanup of the zope/app/form/browser code.
>>
>
> Jim has been complaining vociferously about SimpleInputWidget. It's  
> probably time to nuke it (fine, deprecrete) and replace it with  
> helper functions ala utility.py.
>
> There's quite a bit on the plate here. I'd be inclined to flesh out  
> in more detail the infrastructural pieces (vocab -> source,  
> constraints, widget API refactor) and leave new fields and widgets  
> for later.

That does make sense (though I'd love to finally get those fields and  
widgets out the door).  I don't expect the vocab or constraints stuff  
to take too much time, actually, unless there is disagreement, but  
plans for the widget API might be good to use focused "face time" on.

> I can probably free up some time to look at SimpleInputWidget.

That would be great--you mean, during the same time as the sprint, or  
before, or after?  If before or during, we should probably coordinate.

Thanks

Gary