[Zope3-Users] New set of z3c.form* releases!

Stephan Richter srichter at cosmos.phy.tufts.edu
Fri Aug 24 00:54:21 EDT 2007


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!


More information about the Zope3-users mailing list