Toward better cohesion in the sitemap

[Mark Lundquist <ml...@wrinkledog.com>]

Hi,

Midway through slugging out my first Cocoon app, I've noticed something 
about the structure of the sitemap...

Partitioning the 'container' elements for pipelines the way the sitemap 
does today yields a kind of "utility cohesion" which is not so great.  
The aspects I have in mind specifically are (a) <map:resources> as the 
container for <map:resource>, and (b) @internal-only applying at the 
<map:pipeline> level.

(BTW, the colloquialism seems to be to refer to matchers or selectors 
as 'pipelines', which totally makes sense IMHO.  I'll follow that 
convention here, and I'll use "<map:pipeline>" to refer to that element 
itself.  To be honest, it's not really clear to me what a 
<map:pipeline> is, other than a series of 'pipelines' that share one or 
the other value for the "internal-only" property.  The mismatch between 
the formalism and the colloquialism seems unfortunate...  If I'm 
totally off-base here, I'm sure someone will enlighten me...)

Anyway... when using flow with CForms or JXTemplate, the same pattern 
occurs over and over again in my sitemap:

	<map:match pattern="something">
		<map:call function="showSomething" />
	</map:match>
	<map:match pattern="something.display">	<!-- invoked from flow by, 
e.g. by sendForm() or sendPageAndWait() -->
		.
		.
		.
	</map:match>

Now, the matcher for "something.display" really belongs in an internal 
<map:pipeline>.  But to do that, I have to violate the "functional 
cohesion" of having these two matchers occur together.  I like having 
them together, it makes it easier to tell what's going on (and I can 
make new instances of the pattern with a single "yank/put" in the 
editor...).

I wish that I could just write

	<map:match internal-only="true" pattern="something.display">

Similarly, if I have a resource that's meant to be called by just a 
couple of pipelines, it would be nice to be able to locate it 
contiguously w/ the pipelines that call it — once again, it just would 
make the sitemap easier to follow IMHO.  Especially if you're using 
uplevel naming of matcher parameters (e.g. "{../1}") in the resource.  
If <map:resource> were allowed in the same context as <map:match>, then 
I could put the related elements together in the same "block" or 
division in the sitemap, comment it all together etc.

To do this right, it <map:resource>s would probably need to be nestable 
like matchers, actions etc. — consider a set of pipelines protected by 
<act:auth-protect>... you'd want to be able to locate the resource 
inside the action along with the pipelines that call it.

All this could be naïve, I don't know... I'm still pretty new to Cocoon 
and I probably haven't seen a lot of more sophisticated uses of the 
sitemap, and really don't know what things my suggestion might break.  
In any case, I'd be interested to hear what others think.

~ mark



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: Toward better cohesion in the sitemap

[Joerg Heinicke <jo...@gmx.de>]

On 24.03.2004 18:25, Mark Lundquist wrote:

> Partitioning the 'container' elements for pipelines the way the sitemap 
> does today yields a kind of "utility cohesion" which is not so great.  
> The aspects I have in mind specifically are (a) <map:resources> as the 
> container for <map:resource>, and (b) @internal-only applying at the 
> <map:pipeline> level.
> 
> (BTW, the colloquialism seems to be to refer to matchers or selectors as 
> 'pipelines', which totally makes sense IMHO.  I'll follow that 
> convention here, and I'll use "<map:pipeline>" to refer to that element 
> itself.  To be honest, it's not really clear to me what a <map:pipeline> 
> is, other than a series of 'pipelines' that share one or the other value 
> for the "internal-only" property.  The mismatch between the formalism 
> and the colloquialism seems unfortunate...  If I'm totally off-base 
> here, I'm sure someone will enlighten me...)

No, you are not, at least I have the same feelings here, then we were 
already two :) map:pipeline does not only hold one pipeline and the name 
is therefore irritating. But using pipeline for a matcher is also a bad 
idea:

<map:match pattern="*.xhtml">
   <map:match pattern="*test.xhtml">
     <!-- test files -->
   </map:match>
   <map:match pattern="*">
     <!-- the rest -->
   </map:match>
</map:match>

How many "pipelines" would you have in this sample? Even without nested 
matchers you don't need to have a complete pipeline inside on matcher, 
e.g. when using resources.

> Anyway... when using flow with CForms or JXTemplate, the same pattern 
> occurs over and over again in my sitemap:

     <map:pipeline>
>     <map:match pattern="something">
>         <map:call function="showSomething" />
>     </map:match>
     </map:pipeline>
     <map:pipeline internal-only="true">
>     <map:match pattern="something.display">    <!-- invoked from flow 
> by, e.g. by sendForm() or sendPageAndWait() -->
>         .
>         .
>         .
>     </map:match>
     </map:pipeline>

> Now, the matcher for "something.display" really belongs in an internal 
> <map:pipeline>.  But to do that, I have to violate the "functional 
> cohesion" of having these two matchers occur together.  I like having 
> them together, it makes it easier to tell what's going on (and I can 
> make new instances of the pattern with a single "yank/put" in the 
> editor...).

It's easy to fix as above. More to type, but therefore a map:pipeline 
really contains one pipeline ;-)

I only have one of those pairs in my cforms app sitemap at the moment, 
but that might change.

> I wish that I could just write
> 
>     <map:match internal-only="true" pattern="something.display">
> 
> Similarly, if I have a resource that's meant to be called by just a 
> couple of pipelines, it would be nice to be able to locate it 
> contiguously w/ the pipelines that call it — once again, it just would 
> make the sitemap easier to follow IMHO.  Especially if you're using 
> uplevel naming of matcher parameters (e.g. "{../1}") in the resource.  
> If <map:resource> were allowed in the same context as <map:match>, then 
> I could put the related elements together in the same "block" or 
> division in the sitemap, comment it all together etc.
> 
> To do this right, it <map:resource>s would probably need to be nestable 
> like matchers, actions etc. — consider a set of pipelines protected by 
> <act:auth-protect>... you'd want to be able to locate the resource 
> inside the action along with the pipelines that call it.

For such discussions you probably have to go to the developers list to 
get a response.

Joerg


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org