cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <baro...@nicolaken.com>
Subject Re: Retuning Sitemap Design
Date Thu, 10 Jan 2002 14:05:03 GMT

----- Original Message -----
From: "Stefano Mazzocchi" <stefano@apache.org>
To: <cocoon-dev@xml.apache.org>
Sent: Thursday, January 10, 2002 2:28 PM
Subject: Re: Retuning Sitemap Design


> Hmmm, try to read it from the perspective of somebody who cames from
> XSLT or comes from other programming languages. Which one has a easier
> learning curve yours, or the one we already have?

Which of course applies also to learning two different components that
overlap without knowing what to use.

> Sure, matchers and selectors *DO* partially overlap.
>
> But don't
>
>  for{};
>  while{};
>  do {} while ();
>
> partially overlap?

"While" is a less verbose "for".
You can use the more general "for" to do "while"s but also can do the
opposite.
The're easibly interchangeble.
If one doesn't use the most correct on for the job, he still gets his work
don easily.

> As stated somewhere else, syntax sugar is not always bad.
>
> And as far as implementation, it's pretty easy to write a Select and a
> Matcher using the same logic behind it.
>
> But there is more: semantic overlap triggers some deeper thinking about
> 'which one is better for this'?

They are not interchangeble.

> The problem is when overlapping things are totally equivalent, but this
> is *NOT* the case for matchers and selectors since the first perform
> tokenization, while the second do not.

There's also the "Map return" issue and the "otherwise".

> I'm very happy to provide strict and good rules about sitemap component
> composition, but this won't necessarely mean that semantic overlapping
> will be removed.

IMHO semantic overlap is bad when there is a *big* intersection of roles.
Inclusion or small intersection though is tollerable.

> Moreover, matchers 'match a request' while selectors 'select paths'.
> They clearly separate concerns! Their functionality and implementations
> partially overlap because both require 'conditional operations', but one
> is declarative (matchers) and one is procedural (selectors).

Not really. The matching is done sequentially, so it's kinda procedural.
If you say that multiple matchers can operate on the same request, then I
will agree.

If matching is done like a selection, I don't see a substantial semantic
difference.
If the semantic difference is asking every match in sequence if it wants to
handle the request instead of selecting at the beginning and forwarding,
what's the difference?

Ken
--
Nicola Ken Barozzi                 xml-cocoon@nicolaken.com

These are the days of miracle and wonder...
          ...so don't cry baby, don't cry...
                                                  Paul Simon

Mime
View raw message