cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Pfingsthorn" <m.pfingsth...@hippo.nl>
Subject RE: Cocoon Forms library... some more questions.
Date Thu, 11 Aug 2005 13:10:55 GMT
Hi!

Thanks for the comments, got some more though ;)

> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain@apache.org]
> Sent: Thursday, August 11, 2005 11:56
> To: dev@cocoon.apache.org
> Subject: Re: Cocoon Forms library... some more questions.
> 
> 
> 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!

Yes, definitely! I'll post more when its more mature ;)

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

For now, I thought I might handle it within one library object. A library might have a dependenciesHaveChanged()
method, which would access the local map of dependencies and ask the librarymanager if they
have changed. This method might be called after the librarymanager knows that this library
hasn't changed.

E.g.:

Library lib = (Library)this.cacheManager.get(source, PREFIX);
if(lib!=null && lib.dependenciesHaveChanged()) {
	lib = null;
}
if(lib==null) {
	// load library specified by source
}

The librarymanager would then sort of recursively ask the libraries and we would get a path
of regeneration where needed.

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

Yes, but what is the contract of a widget with the model? That the type stays the same? If
you think about macros more in terms of a template, then you might need to replace something.
But I agree, replace seems a little out of place.

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

<snip/>

> 
> >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? ;-)

Thats what I thought ;)

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

OK.

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

Yes, but we want definitions to be mutable, otherwise we cant change it anymore by extending
it. Or Builders can somehow go around the immutability. The way I think it might be is that
definitions should be kept in the library objects. However, multiple widgets, and therefore
definitions, might be derived from a particular definition in the library. Since we are dealing
with references all the time, we would change the original definition object while deriving
if we didn't make a complete copy of it first.
Ah: Or the builders would be kept by the library. Then they can pump out new definition objects
for every time one is requested. This would mean though that the builders would have some
state, which is not the case right now. And I guess the whole point was to _not_ reparse the
xml all the time.

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

Very nice, I'll have a look!

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

Very much! Thanks!

max

Mime
View raw message