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>
<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
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>
<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.
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
[1]
http://jakarta.apache.org/commons/beanutils/apidocs/org/apache/commons/beanutils/BeanUtils.html
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
