cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Pfingsthorn" <m.pfingsth...@hippo.nl>
Subject Cocoon Forms library... some more questions.
Date Wed, 10 Aug 2005 16:50:58 GMT
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.
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>...

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>

<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>
</fd:macro>

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

<fd:macro expand="mysecondmacro"/> would give:

<fd:field id="firstname">
  <fd:label>firstname</fd:label>
</fd:field>
<fd:field id="lastname">
  <fd:label>lastname</fd:label>
</fd:field>

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.

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

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...

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?

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 ;)

Best regards,

Max Pfingsthorn

Hippo  

Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel  +31 (0)20 5224466
-------------------------------------------------------------
m.pfingsthorn@hippo.nl / www.hippo.nl
--------------------------------------------------------------

Mime
View raw message