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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
