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!