Hi everyone,
in the past month more project-related work, user feedback/requests and
Javascript work has driven the development of the z3c.form framework. There
are many new exciting features. There were also some small refactoring
changes, which might require your CSS and tests to be adjusted. Please read
the changes section below carefully!
As always, the demos can be run using:
$ svn co svn://svn.zope.org/repos/main/z3c.formdemo/tags/1.4.0 formdemo
$ cd formdemo
$ python bootstrap.py
$ ./bin/buildout -N
$ ./bin/demo fg
Thanks to Roger, Windows users should be able to run the demos this way now as
well!
Visually, not much has happened; there are no new demos. However, just wait
until the next round of z3c.formjs* releases!
Changes
-------
- Feature: An event handler for ``ActionErrorOccurred`` events is registered
to merge the action error into the form's error collectors, such as
``form.widgets.errors`` and ``form.widgets['name'].error`` (if
applicable). It also sets the status of the form. (Thanks to Herman
Himmelbauer, who requested the feature, for providing use cases.)
- Feature: Action can now raise ``ActionExecutionError`` exceptions that will
be handled by the framework. These errors wrap the original error. If an
error is specific to a widget, then the widget name is passed to a special
``WidgetActionExecutionError`` error. (Thanks to Herman Himmelbauer, who
requested the feature, for providing use cases.)
- Feature: After an action handler has been executed, an action executed event
is sent to the system. If the execution was successful, the event is
``ActionSuccessfull`` event is sent. If an action execution error was
raised, the ``ActionErrorOccurred`` event is raised. (Thanks to Herman
Himmelbauer, who requested the feature, for providing use cases.)
- Feature: The ``applyChanges()`` function now returns a dictionary of changes
(grouped by interface) instead of a boolean. This allows us to generate a
more detailed object-modified event. If no changes are applied, an empty
dictionary is returned. The new behavior is compatible with the old one, so
no changes to your code are required. (Thanks to Darryl Cousins for the
request and implementation.)
- Feature: A new ``InvalidErrorViewSnippet`` class provides an error view
snippet for ``zope.interface.Invalid`` exceptions, which are frequently used
for invariants.
- Feature: When a widget is required, HTML-based widgets now declare a
"required" class.
- Feature: The validation data wrapper now knows about the context of the
validation, which provides a hook for invariants to access the environment.
- Feature: The BoolTerms term tokens are now cosntants and stay the same, even
if the label has changed. The choice for the token is "true" and "false". By
default it used to be "yes" and "no", so you probably have to change some
unit tests. Functional tests are still okay, because you select by term
title.
- Feature: BoolTerms now expose the labels for the true and false values
to the class. This makes it a matter of doing trivial sub-classing to
change the labels for boolean terms.
- Feature: Exposed several attributes of the widget manager to the form for
convenience. The attributes are: mode, ignoreContext, ignoreRequest,
ignoreReadonly.
- Feature: Provide more user-friendly error messages for number formatting.
- Refactoring: The widget specific class name was in camel-case. A converntion
that later developed uses always dash-based naming of HTML/CSS related
variables. So for example, the class name "textWidget" is now
"text-widget". This change will most likely require some changes to your CSS
declarations!
- Documentation: The text of ``field.txt`` has been reviewed linguistically.
- Documentation: While reviewing the ``form.txt`` with some people, several
unclear and incomplete statements were discovered and fixed.
- Bug (IE): In Internet Explorer, when a label for a radio input field is only
placed around the text describing the choice, then only the text is
surrounded by a dashed box. IE users reported this to be confusing, thus we
now place the label around the text and the input element so that both are
surrounded by the dashed border. In Firefox and KHTML (Safari) only the
radio button is surrounded all the time.
- Bug: When extracting and validating data in the widget manager, invariant
errors were not converted to error view snippets.
- Bug: When error view snippets were not widget-specific -- in other words,
the ``widget`` attribute was ``None`` -- rendering the template would fail.
Enjoy!
_______________________________________________
Zope-Announce maillist - Zope-Announce@zope.org
http://mail.zope.org/mailman/listinfo/zope-announce
Zope-Announce for Announcements only - no discussions
(Related lists -
Users: http://mail.zope.org/mailman/listinfo/zope
Developers: http://mail.zope.org/mailman/listinfo/zope-dev )
in the past month more project-related work, user feedback/requests and
Javascript work has driven the development of the z3c.form framework. There
are many new exciting features. There were also some small refactoring
changes, which might require your CSS and tests to be adjusted. Please read
the changes section below carefully!
As always, the demos can be run using:
$ svn co svn://svn.zope.org/repos/main/z3c.formdemo/tags/1.4.0 formdemo
$ cd formdemo
$ python bootstrap.py
$ ./bin/buildout -N
$ ./bin/demo fg
Thanks to Roger, Windows users should be able to run the demos this way now as
well!
Visually, not much has happened; there are no new demos. However, just wait
until the next round of z3c.formjs* releases!
Changes
-------
- Feature: An event handler for ``ActionErrorOccurred`` events is registered
to merge the action error into the form's error collectors, such as
``form.widgets.errors`` and ``form.widgets['name'].error`` (if
applicable). It also sets the status of the form. (Thanks to Herman
Himmelbauer, who requested the feature, for providing use cases.)
- Feature: Action can now raise ``ActionExecutionError`` exceptions that will
be handled by the framework. These errors wrap the original error. If an
error is specific to a widget, then the widget name is passed to a special
``WidgetActionExecutionError`` error. (Thanks to Herman Himmelbauer, who
requested the feature, for providing use cases.)
- Feature: After an action handler has been executed, an action executed event
is sent to the system. If the execution was successful, the event is
``ActionSuccessfull`` event is sent. If an action execution error was
raised, the ``ActionErrorOccurred`` event is raised. (Thanks to Herman
Himmelbauer, who requested the feature, for providing use cases.)
- Feature: The ``applyChanges()`` function now returns a dictionary of changes
(grouped by interface) instead of a boolean. This allows us to generate a
more detailed object-modified event. If no changes are applied, an empty
dictionary is returned. The new behavior is compatible with the old one, so
no changes to your code are required. (Thanks to Darryl Cousins for the
request and implementation.)
- Feature: A new ``InvalidErrorViewSnippet`` class provides an error view
snippet for ``zope.interface.Invalid`` exceptions, which are frequently used
for invariants.
- Feature: When a widget is required, HTML-based widgets now declare a
"required" class.
- Feature: The validation data wrapper now knows about the context of the
validation, which provides a hook for invariants to access the environment.
- Feature: The BoolTerms term tokens are now cosntants and stay the same, even
if the label has changed. The choice for the token is "true" and "false". By
default it used to be "yes" and "no", so you probably have to change some
unit tests. Functional tests are still okay, because you select by term
title.
- Feature: BoolTerms now expose the labels for the true and false values
to the class. This makes it a matter of doing trivial sub-classing to
change the labels for boolean terms.
- Feature: Exposed several attributes of the widget manager to the form for
convenience. The attributes are: mode, ignoreContext, ignoreRequest,
ignoreReadonly.
- Feature: Provide more user-friendly error messages for number formatting.
- Refactoring: The widget specific class name was in camel-case. A converntion
that later developed uses always dash-based naming of HTML/CSS related
variables. So for example, the class name "textWidget" is now
"text-widget". This change will most likely require some changes to your CSS
declarations!
- Documentation: The text of ``field.txt`` has been reviewed linguistically.
- Documentation: While reviewing the ``form.txt`` with some people, several
unclear and incomplete statements were discovered and fixed.
- Bug (IE): In Internet Explorer, when a label for a radio input field is only
placed around the text describing the choice, then only the text is
surrounded by a dashed box. IE users reported this to be confusing, thus we
now place the label around the text and the input element so that both are
surrounded by the dashed border. In Firefox and KHTML (Safari) only the
radio button is surrounded all the time.
- Bug: When extracting and validating data in the widget manager, invariant
errors were not converted to error view snippets.
- Bug: When error view snippets were not widget-specific -- in other words,
the ``widget`` attribute was ``None`` -- rendering the template would fail.
Enjoy!
_______________________________________________
Zope-Announce maillist - Zope-Announce@zope.org
http://mail.zope.org/mailman/listinfo/zope-announce
Zope-Announce for Announcements only - no discussions
(Related lists -
Users: http://mail.zope.org/mailman/listinfo/zope
Developers: http://mail.zope.org/mailman/listinfo/zope-dev )