Re: [RT] Using modifiers within Cocoon components
On Friday, Oct 10, 2003, at 10:47 Europe/Rome, Stephan Michels wrote: -> Accessible by all blocks, but not outside of Cocoon this is useless and/or harmful. only dependent blocks can have access to the pipeline. scope is already limited by design. BTW, shouldn't the 'root' block decide which resources are public and which are private?! So that everything is protected, except the 'root' block exposes them. no, this level of level protection is done by the dependencies. -- Stefano.
Re: [RT] Using modifiers within Cocoon components
Puh, finally arrived at home. I took some days to visit the belgium coast. The name 'modifiers' comes from the java grammar, and include more than private and public. But if we talking only about accessibility, then @access is ok. On Thu, 9 Oct 2003, Sylvain Wallez wrote: > Geoff Howard wrote: > > > 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. What about using the access modifier 'protected' for internal-only pipelines -> Accessible only by the current sitemap -> Accessible from outside of Cocoon -> Accessible by all blocks, but not outside of Cocoon BTW, shouldn't the 'root' block decide which resources are public and which are private?! So that everything is protected, except the 'root' block exposes them. Stephan.
Re: [RT] Using modifiers within Cocoon components
Stefano Mazzocchi wrote: On Thursday, Oct 9, 2003, at 14:00 Europe/Rome, Geoff Howard wrote: Bertrand Delacretaz wrote: ... I like access="private" and access="public". - Which is the default if none is specified? (public) it would be back incompatible, but defaulting to private would be better from an evolutionary perspective. I was thinking of back compatibility too, but come to think of it which old version of Cocoon with block polymorphism do we have to worry about? ;) Hmmm, on second thought, uri access : @internal-only block access : @access are these two orthoganal concepts named deceptively in the case of pipelines? ... 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. random though, but you could think of "protected" as exposed to extending blocks but not outside that extending block (maybe to allow a different style of wrapping), while "private" is not exposed to extending blocks and public so, leaving block-access="" (on both components and pipelines) is probably a better idea. Sounds good - not sure if we'll need or want those kind of distinctions but it's hard to predict now. Geoff
Re: [RT] Using modifiers within Cocoon components
On Thursday, Oct 9, 2003, at 14:00 Europe/Rome, 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 [...] 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) it would be back incompatible, but defaulting to private would be better from an evolutionary perspective. Hmmm, on second thought, uri access : @internal-only block access : @access are these two orthoganal concepts named deceptively in the case of pipelines? I think so, yes. @access is not meant to imply whether a pipeline can be accessed but whether it can be extended or used outside the block. yes 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. random though, but you could think of "protected" as exposed to extending blocks but not outside that extending block (maybe to allow a different style of wrapping), while "private" is not exposed to extending blocks and public so, leaving block-access="" (on both components and pipelines) is probably a better idea. -- Stefano.
Re: [RT] Using modifiers within Cocoon components
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
[...]
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
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Using modifiers within Cocoon components
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 [...] 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. 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. Geoff
Re: [RT] Using modifiers within Cocoon components
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 [...] 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. -Bertrand
Re: [RT] Using modifiers within Cocoon components
On Tuesday, Oct 7, 2003, at 10:31 Europe/Rome, Stephan Michels wrote: Hi, how about using modifiers like "private" and "public" within the sitemap to expose the components for the next coming blocks. Instead of exposing the components within the block descriptor. [...] I like the concept, prevents from people misinterpreting the contract between blocks. the suggested "access" attribute name is probably a better choice, though. We could use the same syntax for the so called interal pipelines [...] 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. what do others think? -- Stefano.
Re: [RT] Using modifiers within Cocoon components
Jeff Ramsdale wrote: You might consider naming your attribute "visibility" rather than "modifier" for better clarity. As "public" and "private" denote access modifiers, how about simply calling the attribute "access" ? -Original Message- From: Stephan Michels [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 1:32 AM To: cocoon-dev Subject: [RT] Using modifiers within Cocoon components Hi, how about using modifiers like "private" and "public" within the sitemap to expose the components for the next coming blocks. Best regards, Michael Hartle
RE: [RT] Using modifiers within Cocoon components
You might consider naming your attribute "visibility" rather than "modifier" for better clarity. Jeff > -Original Message- > From: Stephan Michels [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 07, 2003 1:32 AM > To: cocoon-dev > Subject: [RT] Using modifiers within Cocoon components > > > Hi, > > how about using modifiers like "private" and "public" > within the sitemap to expose the components for the next coming > blocks. Instead of exposing the components within the block > descriptor. > > > > > > [...] > > We could use the same syntax for the so called interal pipelines > > > [...] > > We could use two different component managers for each sitemap to manage > these components, this should make the lookup easier. > > Just a thought, Stephan. > > ___ > Stephan Michels EMail: [EMAIL PROTECTED] > ICQ: 115535699Tel: +49-030-314-21583 > +|+|+|+|+|+|+|-| > >
[RT] Using modifiers within Cocoon components
Hi, how about using modifiers like "private" and "public" within the sitemap to expose the components for the next coming blocks. Instead of exposing the components within the block descriptor. [...] We could use the same syntax for the so called interal pipelines [...] We could use two different component managers for each sitemap to manage these components, this should make the lookup easier. Just a thought, Stephan. ___ Stephan Michels EMail: [EMAIL PROTECTED] ICQ: 115535699Tel: +49-030-314-21583 +|+|+|+|+|+|+|-|
