cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Judson Lester <jud...@irev2.com>
Subject Re: Retuning Sitemap Design
Date Wed, 09 Jan 2002 22:00:12 GMT
One or two tiny thoughts:

On Tuesday 08 January 2002 06:02 pm, Stefano Mazzocchi wrote:

> + Selectors are conditional components that route the processing from
> two or more choices depending on some selecting logic. They can include
> all components, unless they are inside an aggregator, then they can

<snip/>

>
> + Matchers are conditional components that 'intercept' the request and
> route it to the pipeline components they include. Moreover, they are
> able to pass environment tokens to the included components. Matchers may

<snip/>

There's been a brief exchange in the 'Allowed Sitemap Constructs' section 
(that I got the impression was not the first time it had been brought up), 
the gist of which was the the distinction between matchers and selectors was 
mostly arbitrary.  It would be not terribly hard to merge the two without 
breaking back-compatibility.  Essentially, that <match/> could occur in place 
of <when/> (which would be obsoleted, like the old style function 
declaraction in C), and that <select/> gain an optional attribute that 
allowed it to return maps (<select return-map="true"> ...</select>).  At that

point matchers and selects become completely interchangable, which might help 
to smooth the learning curve slightly, and ease implementation.

Allowing, amongst other things, 
<select return-map="true">
  <match test="...">
     ....
  </match>
  <otherwise>
    ....
  </otherwise>
</select>

but in this case, if the <otherwise/> clause isn't needed, the wrapping 
select can be dropped, or not.

<snip/>
>
> In the example sitemap:
>
>  <map:views>
>   <map:view name="view1" from-position="content">
>    <map:serialize type="s2"/>
>   </map:view>
>
>   <map:view name="view2" from-position="last">
>    <map:transform type="t3" src="..."/>
>    <map:serialize type="s3"/>
>   </map:view>
>  </map:views>
>
>  <map:pipelines>
>   <map:pipeline>
>    <map:generator type="g1" src="..."/>
>    <map:transformer type="t1" src="..." map:label="content"/>
>    <map:transformer type="t2" src="..."/>
>    <map:serializer type="s1"/>
>   </map:pipeline>
>  </map:pipelines>
>
> for any URI the views will do
>
>  default (no view):   g1 -> t1 -> t2 -> s1
>  view1:               g1 -> t1 -> s2
>  view2:               g1 -> t1 -> t3 -> s3

Shouldn't view2 be g1->t1->t2->t3->s3?  Otherwise I'm very confused.


> Structure Validation
> --------------------
>
> The sitemap should be checked for structure inconsistencies or mistakes
> at load-time.
>
> Checks include:
>
>  1) all handled requests must pass thru a (generator|serializer) pair or
> a reader.
>
>  2) readers must never find the other direct components during a
> pipeline processing.
>
>  3) mount and redirect-to must never be found after a direct component.

Is it out of line to propose a 
4) actions (or perhaps, more generally, components) which can never be 
reached?

I've always felt that a more important purpose of error checking was to aid 
the developer, rather than ensure simple program correctness.  Isn't this 
part of why we all use Java rather than C++?  


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


Mime
View raw message