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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
