cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <>
Subject Re: CForms Summer of Code project
Date Mon, 13 Jun 2005 18:51:34 GMT
On Fri, Jun 10, 2005 at 12:46:09AM +0200, Max Pfingsthorn wrote:
> Hi again!
> This is mainly to Reinhard and Sylvain, I guess. Who else is a CForms
> guru here? :)
> I have a question about the inheritance and namespace/inclusion
> semantics which are not really discussed in the wiki.
> 1. What about nested libraries? In the wiki it says it forms a flat
> namespace. Would that be like this: include library 1 as "lib1" and
> library 2 (from library 1) as "lib2", then all macros of lib2 will
> still be accessible as lib2:name in a definition which includes lib1?
> It also mentions a tree like model (I guess like java packages?),
> which would result in "lib1:lib2:name" to resolve to a macro in lib2?
> I guess both would be sort of easy to implement.

Think of it like a tree, where each level can only see its
own direct imports.  For a library to expose macros from
the libraries it imports it has to extend them, in effect
adding those macros to its own namespace.  In other words,
when you import a macro library you can only see the macros
that the library itself defines or extends, not macros that
the library just happened to import for its own use.
(This merely describes the current design and implementation
in whiteboard/forms, feel free to change/improve it.)

> 2. Can any widget type be macro-ized or only fields? I guess any would
> make sense... Can macros be extended in the form definition?

Any type of widget or list of widgets.

> 3. Extension/Inheritance of widgets may be a problem as currently the
> validation of configs is done within the builders'
> buildWidgetDefinition() method. May need to implement
> "extendWidgetDefinition(Element, WidgetDefinition)" for each of the
> builders. Default may be to just return the given definition. Could be
> called in AbstractWidgetDefinitionBuilder.buildAnotherWidgetDefinition().
> Do you think that would that solve it?

It has been a while since I thought about that part...try
it and see how it works out.

> 4. What exactly is the NewDefinition for? For dynamic form generation?
> In that case, I guess, I can reuse some of it's parts for the
> MacroDefinition(Builder), yes?

I copied and modified the Class and New defintions to make
the "macro" support in whiteboard/forms.  Class is for
creating a blueprint of a list of one or more widgets, New
says "build an instance of that blueprint right here".
"New" happens at the normal form-build time, so it is not
really any more dynamic than saying <fd:booleanfield.../>.

> 5. What about caching or reloading libraries if they changed? How is
> that handled right now?

Iirc, they are cached indefinitely, and checking for
out-of-dateness only happens one level deep.  An area for
improvement :)

Have fun,
--Tim Larson

View raw message