cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: CForms Summer of Code project
Date Fri, 10 Jun 2005 06:04:26 GMT
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 ( 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?

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

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


Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}


View raw message