cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: CForms Summer of Code project
Date Fri, 10 Jun 2005 10:46:46 GMT
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


Mime
View raw message