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

[Gary Poster]

On Aug 30, 2005, at 9:13 PM, Stuart Bishop wrote:

> Gary Poster wrote:
>
>
>> 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've just had to wade through this recently. In particular, I had  
> to resort
> to ZCML overrides to get around the HTML quoting embedded in the  
> guts of the
> form validation error rendering - we need XHTML markup in our error
> messages. If this is worked on it would be nice if this use case was
> remembered ;) I suspect we want to use views on the exceptions so  
> we can
> easily provide HTML snippets or plain text string renderings.

OK, good feedback.  Thanks.

>> 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*
>
> Constraints can already raise ValidationError whose doc() method  
> returns the
> error message. Although this seems to be undocumented and may only be
> working for us by accident...

Interesting point.  The interface doesn't seem to support this  
approach...

     def constraint(value):
         u"""Check a customized constraint on the value.

         You can implement this method with your Field to
         require a certain constraint.  This relaxes the need
         to inherit/subclass a Field you to add a simple constraint.
         Returns true if the given value is within the Field's  
constraint.
         """

...but that doesn't mean we can't bless it retroactively. :-)  That's  
definitely worth evaluating, as that would mean fewer changes.  I  
think I'd be fine with just expanding the contract a bit...

>> 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*
>
> You mention code exists - is it available anywhere? We were looking  
> into
> similar things but I'm not sure what the status is (I think we have  
> some
> suitable client side javascript, but I havn't seen it running yet).

We have not yet released this--it is in a package that needs some  
TLC, as I said at the beginning of the original note, and it relies  
on another piece that we are in the process of proposing.  If there  
is some time pressure for this, let us know, and we'll see if we can  
accelerate some of this enough for you all to at least evaluate from  
the sandbox.

Gary