cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Using modifiers within Cocoon components
Date Thu, 09 Oct 2003 12:32:27 GMT
Geoff Howard wrote:

> Bertrand Delacretaz wrote:
>> Le Jeudi, 1 jan 1970, à 13:40 Europe/Zurich, Stefano Mazzocchi a écrit :
>>>> ...We could use the same syntax for the so called interal pipelines
>>>> <map:pipeline modifier="private">
>>>> [...]
>>>> We could use two different component managers for each sitemap to 
>>>> manage
>>>> these components, this should make the lookup easier.
>>> I like this as well. internal-only="true" sounds hacky.
>> +1, but someone mentioned using
>>   access="private"
>> instead, which is clearer.
>> "modifier" does not convey the exact meaning.
> I like access="private" and access="public".
> - Which is the default if none is specified? (public)
> Hmmm, on second thought,
> uri access : @internal-only
> block access : @access
> are these two orthoganal concepts named deceptively in the case of 
> pipelines?  @access is not meant to imply whether a pipeline can be 
> accessed but whether it can be extended or used outside the block.

I think your analysis is right: @internal-only is related to the origin 
of the request, while @access is about inter-block relations. It may 
make sense to have a pipeline with internal-only="true" and 
access="public", meaning it's not visible from the non-Cocoon world 
(i.e. only through "cocoon:" requests), but that other blocks can use it.

> If we never envision anything other than private/public would 
> something like block-private="true" convey more meaning? 
> block-access="private" might do the same but leave freedom for other 
> than private/public.

Blocks can be extended, and so having "protected" along with "public" 
and "private" may be needed. I don't see a need for "package" 
visibility, though.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message