cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Allowed Sitemap Constructs
Date Thu, 03 Jan 2002 14:37:01 GMT
Carsten Ziegeler wrote:
> 
> Hi,
> 
> I currently run into the problem that I created pipelines which I
> thought were possible, but currently are not support by Cocoon:
> 
> It is not possible to nest anything other than a map:part into
> a map:aggregate, so the following doesn't work:
> <map:aggregate>
>   <map:select type="test">
>     <map:when test="a">
>       <map:part src="a"/>
>     </map:when>
>     <map:otherwise>
>       <map:part src="b"/>
>     </map:otherwise>
>   </map:select>
>   <map:part src="constant"/>
> </map:aggregate>
> 
> Is this a bug or is this by design?

I didn't partecipate in the design of the 'aggregating' semantics of the
sitemap, but I would think the above is a bug. I don't see why it
shouldn't be possible to use the above since it would be useful in many
situations.

> My personal opinion is, that this should be possible.

I tend to resonate with your vision.
 
> Another restriction we currently have is already entered as a bug with
> the number 4357: An Action is not possible as a root element inside
> a map:pipeline, only map:match can be a used as a root element.
> So here again, is this by design?

oh, god, this is a big one.

Here the restriction is by design, but I do see the need to question it.

My perception is that this might open to door to a shitload of semantic
changes to adapt to the required flow-map like semantics.

But at the same time, I do see the need for use of match-less actions:
the question is how much of a 'hack' this is.
 
> I think we shouldn't make such restrictions. But at least if we make
> these restrictions we should document them.

+1 for documenting all the restriction. This is obvious.

-0 for allowing this change before the flowmap semantics are being
worked on. I mean: if you allow something like

 <pipeline>
  <act name="pre-matching"/>
  <match>...</match>
  <match>...</match>
  <match>...</match>
 </pipeline>

people start doing

 <pipeline>
  <act name="pre-matching"/>
  <match>...</match>
  <match>...</match>
  <match>...</match>
  <act name="post-matching"/>
 </pipeline>

and then

 <pipeline>
  <act name="pre-matching"/>
  <match>...</match>
  <act name="intra-matching"/>
  <match>...</match>
  <match>...</match>
  <act name="post-matching"/>
 </pipeline>

but then the question is: is "intra-matching" performed if the first
match is successful?

Placing map:act at the same level of map:match can be perceived as a
design mistake, but might not be since 'matcher' and 'actions' are not
pipeline components since they don't work on the pipeline directly.

So, the options I see are:

1) make it illegal to have unmatched actions

2) encapsulate unmatched actions in defined places

 <pipeline>
  <pre-matching>
   <act>
  </pre-matching>
  <match>...</match>
  <match>...</match>
  <match>...</match>
  <post-matching>
   <act>
  </post-matching>
 </pipeline>

3) make it illegal to have intra-matching actions

[the option of allowing intra-matching actions is, IMO, wrong by design]

The real question is: are those unmatched action useful in real life?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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


Mime
View raw message