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 https://svn.apache.org/repos/asf/cocoon/gsoc/mpfingsthorn/forms (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: http://cocoon.zones.apache.org/daisy/documentation/forms/685.html [2] Original proposal: http://wiki.apache.org/cocoon/CocoonFormsLibraryProject Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 ------------------------------------------------------------- [EMAIL PROTECTED] / www.hippo.nl --------------------------------------------------------------
