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
-------------------------------------------------------------
[EMAIL PROTECTED] / www.hippo.nl
--------------------------------------------------------------
