cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Hartle <>
Subject Re: [RT] Cocoon web applications
Date Sun, 07 Oct 2001 23:22:31 GMT
Stefano Mazzocchi wrote:

>>large CWAs are going to happen (they will, right ?), the sheer length of
>>the list of "parameters" for customizing them could well justify this
>Well, I don't think the number of parameters depend on the size of the
>CWA being deployed and I don't think I get your point.
With "large" CWAs I meant possibly as complex systems as project 
management, groupware or financial/commercial components. The interest 
in developing off-the-shelf drop-in CWAs that can be composed and 
interconnected will more likely lead to more configuration options 
(parameters) than not. Maybe you have another estimation on that.

If those configuration options/parameters are not being passed or 
maintained by defined means of Cocoon, each CWA will solve this problem 
on their own by web forms or seperate configuration files, unnecessarily 
duplicating work of developers and maybe hinder the use of CWAs.

>>This would even allow passing on an instance of configuration source to
>>the CWA, this instance implementing some ConfigurationSource-interface -
>>be aware that I am not sure whether such an interface or class with this
>>name is already existing, and I am not knowingly referring to anything
>>here as I just made a wild guess how this could be named. This might be
>>an LDAPConfigurationSource or a FileConfigurationSource, being able to
>>deliver arbitrary configuration information to the CWA as a stream of
>>SAX events.
>Normally, configurations are strings or numbers. Do you really want to
>receive a stream of SAX events that you have to write your own code to
>interpret, instead of being able to simply *ask* a configuration
>repository for the configuration you want?
I think we basically misunderstood each other in respect to the amount 
of information that may be required as configuration for a CWA; I so far 
am thinking that this might not be done with passing 2 or 3 name/value 
pairs to any app. I consider the term configuration to be a potentially 
hierarchical collection of one or more key/value combinations.

Ok, I agree with you on the part that many small and simple applications 
will be satisfied with just asking for one or two strings or numbers. 
Why not basically use SAX events, giving small applications some utility 
classes at hand that helps doing exactly and solely this while 
developers of more complex apps might decide for themselves what they need ?

>>And those ConfigurationSource's could be defined in the
>>sitemap and being configured with parameters when needed. Hey, why not
>>simply consider different configuration sources as sources for SAX
>>events directly ?
>Because this is exactly what flexiblity syndrome looks like: when you
>have a hammer in your hand, everything looks like a nail.
I rather like to open-mindedly check everything in advance before 
stepping into nails; this does not necessarily mean that this 
flexibility needs to be exercised all the way through, but left as a 
possible way to go in case it is needed.

>>>each CWA indicates
>>>   o  its role as a URI  (
What about putting the version in major.minor format into the URI, like 
it is being done with namespace URIs like 
"" or 
"" ?

>>I am always fearful of prompts that do something for me that I may not
>>have understood completely. 
>This is why the CWA will also contain a description of the configuration
>that you are being asked to provide.
I will correct my sentence: I am always fearful of automated processes 
and prompts that do something for me that I should at least once have 
done for myself manually in order to understand it completely.

>>Do we speak of a solely installer-based
>>approach here or might this allow the admin to just drop-in the .cwa
>>file and add an entry to the sitemap without anything able to directly
>>prompt at all ?
>As you guys wish, I don't see any reason to force one behavior or the
I think the installer-based approach with prompting the user is 
something to be left for a seperate deployment tool.

>>We should give the administrator a way to explicitly name a certain
>>instance, leaving the administrator the choice between automatic
>>GUI-driven and good-old vi-driven approaches, as the admin can partially
>>or completely override the naming scheme and refer CWA dependencies to
>>their targets manually. Whenever people would use the dynamic naming
>>scheme to ensure multiple installations do not collide, they show a
>>certain lack of interest to make sure they connect CWA dependencies
>You got the wrong perception here, since I'm trying to help
>administrators instead of doing stuff for them behind their backs. But
>if you don't like that, fine, you'll always have the good old
>configuration files to modify by hand.
Helping administrators is a good thing and will certainly be rewarded; I 
am by no means having a vi fetish, but I think that being able to modify 
the configurations by hand has its advantages such as speed.

Best regards,

Michael Hartle

To unsubscribe, e-mail:
For additional commands, email:

View raw message