cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Access to the object model
Date Wed, 21 May 2003 08:24:30 GMT
Stefano Mazzocchi wrote:

>on 5/20/03 3:57 PM Sylvain Wallez wrote:

>>Well, I have to explain further how my project using the CVSSource works 
>>(gee, will you find it hacky also ?).
>>This is a lightweight CMS working with a repository. The sitemap doesn't 
>>care if this is CVS, slide, files, or any other modifiable source, or a 
>>combination thereof, and actually doesn't use "cvs:" at all. All calls 
>>to the repository use a "repo:" protocol which is equivalent to a 
>>mounting table :
>>        <protocol name="repo" class="...">
>>            <!-- source mappings : maps a top-level directory 
>>("repo:/topdir") to another source
>>               "from" attribute : top-level directory (first path element)
>>               "to" attribute : target mount point.
>>            -->
>>            <map from="spec" to="cvs:auth:/spec/"/>
>>            <map from="man"  to="cvs:auth:/man/"/>
>>            <map from="gen"  to="cvs:/gen/"/>
>>            <map from="img" to="file:/app-dir/data/img"/>
>>        </protocol>
>>So the sitemap actually contains <map:generate src="repo://spec/foo"/> 
>>where user credentials cannot fit.
>>The scheme you propose, even if it works, requires to repeat the 
>>authentication scheme everywhere the repository is used. It also has the 
>>potential bad side effect of showing user credential in clear text in 
>>the logs or in an error screen (e.g. ResourceNotFoundException).
>Now, my question remains: the flow has access to the object model and the flow has access
to the component, why don't you use that as the glue between them and leave IoC intact?
>What am I missing?

In this use case, flow is of no use in the publication part of the 
application, which are just straight pipelines. Or do you mean that a 
script could be used to prepare some sitemap variables ? This seems 
overkill to me when a simple and more readable declarative approach can 
do the job.

Also, I don't understand why giving access to the object model through 
the Avalon context breaks IoC, as the object model is still given to the 
components that require it by an external container-controlled object.

I even find it cleaner than having to pass the object model as a 
parameter down to components that need it, eventually having to pass it 
through components that absolutely don't care about it. And if the call 
chain goes through components that don't allow the transmission of the 
object model, then you're stuck to the ugly 


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message