[Zope-dev] z3c.form 2.0

[Dan Korostelev]

2009/2/10 Stephan Richter <srichter at cosmos.phy.tufts.edu>:
> On Monday 09 February 2009, Dan Korostelev wrote:

>> FileWidget - It doesn't clear the bytes value if no new file is
>> uploaded now, which is nice. But there's also should be a way to clear
>> current value if the field is not required. I've added that to the
>> TODOS.txt. I think that should be done before release to make the
>> widget actually functional out of box.
>
> Since this feature has not been there before, I can live without it for the
> 2.0 release.

Well, if that will be the only issue left, I'm personally also fine
with releasing without it :))

>> However, there was some backward-incompatible
>> refactorings (class renames) done to sequence data converters that
>> breaks the z3c.pt benchmarking suite. This may also break end-users'
>> code so we probably want to fix the compatibility.
>
> Yeah, let's fix that.

I'll check that.

>> Tests - All are passing.
>
> Clearly, all testsshould be passing. In addition, I would really like to see
> 100% test coverage after taking the false positives into consideration.

Ok, the fix for the "z3c.ptcompat merge break" was to provide a
zope.testing.doctest as a doctest module for testing.OutputChecker, so
all tests pass again. They are also mostly 100% covered. Most
uncovered bits are in the ObjectWidget, MultiWidget and its
combination. So those modules defenitely need a review. :-)

> If translations are not updated until the next release, 2.1.0 or 2.0.1, that's
> fine with me.

Well, that's actually fine with me as well (as I've already updated my
translation :-P), so that was a call for people who wants to get their
translations ready for 2.0.0.

>> One more thing I'd like to do is to add "klass" and "id" to the forms
>> themselves so one could easily customize the visual appeal of the
>> forms. But it's probably should be done in z3c.formui's subclasses and
>> not in z3c.form's base classes. I'd like to hear the community opinion
>> on that though.
>
> All nice to have. :-) I would not block the release because of it.

That's fine with me to do that for the next release. BTW, I just
discovered that forms have the "id" attribute, but it really points to
the "name" which is a read-only property based on prefix, so they are
not customizable at all. Was that done on purpose? I'd just set those
attributes in the `update` method of the form. What do you think?

-- 
WBR, Dan Korostelev