Reinhard Poetz wrote:
Max Pfingsthorn wrote:
Hi again!
This is mainly to Reinhard and Sylvain, I guess. Who else is a CForms
guru here? :)
IIRC the idea came from Tim Larson who has also started with some
experimental code
(http://svn.apache.org/repos/asf/cocoon/whiteboard/forms/) but I have
to admit that I don't know what the current status of it is.
The design and the implementation will be discussed on this list and
anybody who's interested can take part in the discussions. I'm willing
to take the role of the official mentor but I would like a co-mentor
who knows cForms in depth (Sylvain, Tim, Bruno, ...). This person
doesn't need to be officially named but he is more a backup for Max if
the whole community is on holidays and he needs a contact person for
technical questions. Tim has already offered to help "unofficially",
right? (Just asking again for Max.)
I also want a second person as official mentor as I will be offline
for some weeks over the summer. Anybdoy volunteering?
Me, me :-)
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.
leave it open for now. We will have to talk more about usecases and
decide then.
2. Can any widget type be macro-ized or only fields? I guess any would
make sense...
any type
Can macros be extended in the form definition?
hmmm, good questions. I'd say yes, but I can't think of a simple
syntax now. Ideas?
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?
I hope somebody who with in-depth knowledge can answer this.
Me too :-)
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?
same here as before
5. What about caching or reloading libraries if they changed? How is
that handled right now?
AFAIU, when the form is created by the FormManager it gets all its
widgets set. If a library of the form is changed after that, this
doesn't have an impact on "living" form instances.
Sorry if I am rambling a bit... Once I get this straightened out, I
will post my ideas for a solution on the wiki, like requested.
Fine!
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
