Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Message-ID: <4073D124.9080106@gmx.de>
Date: Wed, 07 Apr 2004 12:00:04 +0200
From: Joerg Heinicke <joerg.heinicke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: Toward better cohesion in the sitemap
References: <3B376616-7DB8-11D8-9989-000A95908E0E@wrinkledog.com>
In-Reply-To: <3B376616-7DB8-11D8-9989-000A95908E0E@wrinkledog.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

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