Philipp von Weitershausen wrote:
Looking at the output generated by formlib, I got the impression
nobody cares much about valid output.
formlib's standard template is horrible. zope.app.form's rendering is
much better. I have no idea why formlib uses its own horrid template any
way, it could simply have used widget_macros from zope.app.form (which
is what I always do in my formlib forms).
Well. I can't see why Zope 3 has to ship with two completely different
implementations of widget rows and I don't like the formlib template
either. But this is not the code that causes validation errors.
AFAICS the biggest problem are the poorly maintained widgets in
I object; this is still a change to the contract.
Well. It depends on the point of view. This seems to be the implicit
contract. The templates in zope.formlib and in zope.app.form use the
widget name in the 'for' attribute, so they depend already on that
behavior. Making this contract explicit by fixing the description in
the interface doesn't mean to change the contract. Or does it?
The description of interface methods and attributes are part of the
contract. We should therefore be reluctant to change them, unless
* we just add documentation
* we now explicitly state a contract that has been assumed implicitly
I think this would be the case if we choose the more pragmatic solution.
This looks like overkill to me. No use case comes to my mind where
focusControlId would be different to labelControlId.
But if Zope 3 policies require a new interface for changes like that
and if we really want to stick that close to the HTML specification
I'm fine with adding IWidgetControlInformation.
I'm not an expert on the exact HTML mechanics here, but it always sounds
good to me to stick close to existing specs. The HTML spec is what
people can refer to and what people know...
I'd say people don't care about the specs as long as validators and
browsers don't complain. But maybe this is too pragmatic.
Zope3-dev mailing list