cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Cocoon Forms library... some more questions.
Date Thu, 11 Aug 2005 09:56:18 GMT
Max Pfingsthorn wrote:

>Hi everyone!
>Sorry that I haven't touched base for so long, but I am pretty busy... I've been working
on Slide a lot and I've been implementing yet another Schema to CForms transformation, both
for my wonderful employer.

Is the schema to CForms something that could be contributed? That would 
be really great!

>Anyway, I've finally found some time to write some more code and now I've come across
these few things... I thought it would be nice to get some input from you guys:
>1. Macro expansion, at library-build-time, definition-build-time or instance-build-time?
I guess this is a performance thing, both ways: Takes more time to instantiate a form, but
if a library deep in the inclusion tree changes, you don't have to reload all levels on top.
Kinda want to avoid what bothers me the most with <xsl:include>...

I would avoid if possible instance-build-time for performance reasons. 
About reload management, there could be a kind of include tracker where 
all includes files are registered.

>2. Macro inheritance? I would imagine something like:
><fd:macro define="mymacro">
>   <fd:field id="field">
>     <fd:label>mylabel</fd:label>
>   </fd:field>
><fd:macro define="mysecondmacro" extends="mymacro">
>   <fd:field id="firstname" replaces="field">
>     <fd:label>firstname</fd:label>
>   </fd:field>
>   <fd:field id="lastname">
>     <fd:label>lastname</fd:label>
>   </fd:field>
>Instead of "replaces", I could think of (goes for library-level reuse too):
>- replaces: well, completely replace other widget
>- base: make a new widget alongside the other one, but take the other as a base
>- extends: elaborate on the definition of the other widget, no new widgets created

I may have missed something, but this "replace" thing seems to me to 
introduce way too much complexity. If you make the analogy with classes, 
a subclass cannot remove a method of its parent class and replace it 
with something else. It can however overload it to provide more, while 
still respecting the contract of the parent class.

BTW, macros don't seem to me very different from other container widgets 
such as repeater or even form, and this behaviour should actually be 
consistent among all container types.

><fd:macro expand="mysecondmacro"/> would give:
><fd:field id="firstname">
>  <fd:label>firstname</fd:label>
><fd:field id="lastname">
>  <fd:label>lastname</fd:label>
>I think we can implement rules for everything the DefinitionBuilders do for inheritance
(i.e. by defining a label, it replaces the old one, and by defining a static selection list
it extends the old one, etc...) inside the specific DefinitionBuilders. They should do the
parsing/setting of the definition objects, but the validation should be up to the definition
itself. This way, we can have partial definitions present in the library objects ready for
extension and use at the same time.

Makes sense. A definition should check its consistency and completeness 
on the first call to createInstance().

>3. The wiki page said, there was support for parameterized macros, but I don't see it...
Any pointers?

Hmm... what about considering parameter-less macros for now? ;-)

>4. Library object: Should it be a standalone thing or rather a AbstractContainerDefinition
(like in the whiteboard code)? I don't see the big use of it being a widget yet...

Me neither. Furthermore considering that it doesn't really make sense to 
instanciate a library!

>5. Deep copying of widget definitions: This needs to be possible to keep the definitions
stored in the libraries intact. This might be a hassle, especially with selection lists and
all that extra stuff. Does anyone have an idea how to do this without implementing it for
every widget?

What do you mean by "deep copying"? Is it copying in a definition the 
elements that are reused from the definition it extends? I don't think 
it should be deep: since a definition is immutable, just copying the 
needed information from the extended definition should be enough.

And to avoid typing too much code, you can use the nice BeanUtils class 
[1], either using copyProperties() or iterating on copyProperty() using 
a class-specific list of properties to be copied.

>I am looking forward to some input!
>By the way, I know I am behind... But it is still a "long" time to September 1st, so I
might just make it. Next weekend should be free (finally), so I'll be coding then. It would
be great if we could address some of the issues above before that so I can dive in big time

Hope this helps!



Sylvain Wallez                        Anyware Technologies
Apache Software Foundation Member     Research & Technology Director

View raw message