cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Pfingsthorn" <>
Subject Google Summer of Code - the last minutes
Date Mon, 05 Sep 2005 10:21:50 GMT
Dear Cocooners,

First of all I would like to thank the community for the great experience here. I really loved
being part of the team! :)
Now, a few minutes before the extended deadline, I am finally _done_. All samples work, docs
are written and tests pass! Its a great feeling ;)

Here is a little description of what I did:

It is now possible to write separate collections of widget definitions and bindings which
can be dynamically included. These are called libraries and can be imported into other libraries
or form definitions/bindings. This doesn't mean these are automatically used in the including
definitions or bindings, but they are available for reuse. Also, cache validation is checked
recursively through all dependencies, so if a library deep in the inclusion tree changes,
the complete path to the final definition or binding will be invalidated. This is something
I always disliked with <xsl:include/>, so I fixed it here.

There are three features implemented now:
- Importing of external libraries into another library or form definition
  This works by mapping names to uris like so '<fd:import prefix="name" uri="some/uri/to/a/library"/>'.
Widgets inside the library can be referenced using "name:widgetId".

- Instantiating widgets from imported libraries
  This is done via 'fd:expand id="name:widgetId"/>' and directly evaluates to the referenced
WidgetDefinition. This means that if a definition is expanded in a library, it can be reused
in an importing definition/binding as if it was defined in the library itself.

- Inheriting from other definitions/bindings
  An extra attribute "extends" on any widget definition or binding will cause the referenced
entity to be resolved and used in the initialisation of the current definition or binding.
This way, it is possible to override things like ids, datatypes, labels, xpaths and such and
add things like validators or new child widgets or bindings. Widgets may also extend other
widgets in the same container, meaning for example two widgets in the same group may extend
each other, or two top-level widgets in a form may do the same. Not though that it is not
possible to form cycles as references are resolved right away and cycles will result in silent
ignores because of nonexisting widgets. This should change to complaining exceptions, and
the code is there, just has to be uncommented.

There are a few restrictions though: The complex Tree widget unfortunately does not support
inheritance yet, however you can define it in a library and expand it in your form if you
use it in many places. Also, single validators can only be added, not replaced or extended,
since there is no way to address them right now. Same goes for selection list items, it is
only possible to reset the selection list to something else.

In case you want to know more, you can read the daisy page documenting the library subsystem
[1]. My original proposal is still on the wiki [2].
To testdrive the new forms features, do this:

- in your working copy of the trunk, cd to src/blocks/forms/trunk
- svn switch
  (svn will switch this part of the path to the repository above and update your working copy)
- do a build in the root of the working copy
- check out the forms samples!

Thanks again for your opportunity and I am very much looking forward to contribute some more!

Best regards,

Max Pfingsthorn

[1] Daisy page:
[2] Original proposal:


Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel  +31 (0)20 5224466
------------------------------------------------------------- /

View raw message