Return-Path: 
 <dev-return-47030-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 89070 invoked from network); 29 Aug 2003 09:10:28 -0000
Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 29 Aug 2003 09:10:28 -0000
Received: (qmail 31813 invoked by uid 500); 29 Aug 2003 09:09:43 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 31741 invoked by uid 500); 29 Aug 2003 09:09:42 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 31645 invoked from network); 29 Aug 2003 09:09:41 -0000
Received: from unknown (HELO pulse.betaversion.org) (217.158.110.65)
  by daedalus.apache.org with SMTP; 29 Aug 2003 09:09:41 -0000
Received: (qmail 16126 invoked from network); 29 Aug 2003 09:09:49 -0000
Received: from unknown (HELO apache.org) (stefano@151.25.174.231)
  by pulse.betaversion.org with SMTP; 29 Aug 2003 09:09:49 -0000
Date: Thu, 28 Aug 2003 17:27:46 +0200
Subject: Re: [RT] Improving Sitemap and Flowscript
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Stefano Mazzocchi <stefano@apache.org>
To: dev@cocoon.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <biijib$ir8$1@sea.gmane.org>
Message-Id: <2D422830-D96C-11D7-B683-000393D2CB02@apache.org>
X-Mailer: Apple Mail (2.552)
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N


On Wednesday, Aug 27, 2003, at 17:41 Europe/Rome, Nicola Ken Barozzi 
wrote:

> >Calling a resource, inserting a virtual pipeline and using the 
> cocoon: protocol are for most uses equivalent.<

I agree when you say that since the introduction of the cocoon: 
protocol, map:resource is now redundant (and less appealing, as well). 
In fact, we could go as far as saying that <map:resource> is no longer 
needed and could be deprecated.

This would leave us only with pipelines, components and virtual 
components (which are, in fact, typed pipeline fragments), and the 
cocoon: protocol to mix them, if needed.

> What remains is the <views> part, that has introduced pipeline-stage
> metadata, as a label. It's an aspect that gets called when that
> particular condition is met
>
> >IOW, I'm rephrasing, using different terminology, that a view is an 
> orthogonal mechanism, that interacts with the normal sitemap using 
> some metadata and an exit pipeline.
> The labels are effectively metadata, as they describe the pipeline.
> The exit pipelines, ie the views themselves, are what has to be done.
> <

Yes, views are orthogonal pipelines.

> (I won't use AOP terminology that I personally don't yet like)
>
> >See, I don't like it too! ;-)<

well, when you propose something like <map:aspects> it seems AOP-ish 
enough for me ;-) that's not coherent with the above.

> So we can generalize it, and add configurability to the view mechanism
> to specify other conditions.
>
> >Thus views effectively insert pipeline fragments at a certain 
> condition. In fact they insert their contents after a label.
>
> So the label is the condition.

I know it's a matter of terminology pickyness, but I disagree. The 
condition that triggers the view is the view request. The result of 
this condition is the execution of the pipeline that is 'instrumented' 
to route its output somewhere else (to the view, which can now be seen 
as a virtual serializer)

> *first proposal*
> I propose that we define other conditions.<
>
>    <map:view name="content" from-label="content">
>      <map:serialize type="xml"/>
>    </map:view>
>
> becomes:
>
>    <map:view name="content" type="from-label"
>                             test="content">
>      <map:serialize type="xml"/>
>    </map:view>
>
> This makes it possible to make a different position where to start 
> from...


> What can also be made configurable is *when*, in which condition, it's
> triggered, but the logic has to be inverted.
>
> >What I mean here is that views are triggered only by the user. Normal 
> results are done *without* calling views. So if I want to say: insert 
> a logger after each generator, I cannot do it easily, as I would have 
> to call a "logger-view" for it to be called. And I would have only one 
> possible insertion per pipeline, as only one view is called at a > time.<

ok, now I get it

> Now we say: "when the view is triggered, start at a label"
> After it could be:  "when the view is triggered, start at position"
> Instead we need: "when the position is met, check if it has to be
> triggered".
>
> Here is an example that uses this "inverted" AOPish system for views.
>
> >Let me rephrase this: the following is a way of defining views in a 
> more generic way. Here I don't say anymore: "when the user asks for a 
> view trigger the label (or more generic as in the first proposal) 
> condition", but "at every stage check if a condition is met, and if so 
> execute the "generalized view".

hmmmmm

> *second proposal*
> Make it possible to tell Cocoon to add pipeline snippets (ie virtual 
> pipelines) given certain rules. This makes it possible to have views 
> be made with this more generic mechanism.
> <
>
> The following adds two aspects:
>   - an aspect gets called from every content position and gathers 
> links.
>   - the other one gets called from every content position. If the
> request has a cocoon-view=links, then the links are serialized.


> <map:aspects>
>   <map:aspect type="from-label" test="content">
>     <!-- Any required link munging -->
>     <map:transformer type="gather-links"/>
>   </map:aspect>
>   <map:aspect type="from-label" test="content">
>      <map:action type="request-param">
>        <map:param name="cocoon-view" value="link">
>        <map:serializer type="links"/>
>      </map:action>
>   </map:aspect>
> </map:aspects>

you are using AOP the micro-granular way. This is: remove crosscutting 
by making all overlapping aspect objects and compose them together.

I tend to dislike this practice since it leads, IMHO, to poor 
readability (users don't have the vision of crosscutting concerns that 
we developers do, and they perceive it as unnecessary 
overcomponentization)

a critic to the above is: why would you want to gather-links if you are 
not going to serialize them?

You are suggesting that a more general aspect-oriented approach to 
pipeline composability might be general enough to allow views to be 
replaced by such a more powerful approach.

I agree.

What I don't understand is why we should give away a perfectly fine 
system for a new flexibility we don't need. [note how I avoided to 
named this FS even if I was very tempted to do so ;-)]

> This would make it very easy to add security-based checks, logging, or
> any other stuff.
>
> <map:aspects>
>   <map:aspect type="pipeline" test="start">
>     <map:action type="check-security"/>
>   </map:aspect>
>   <map:aspect type="pipeline" test="all">
>     <map:transformer type="logger"/>
>   </map:aspect>
>   <map:aspect type="error" test="all">
>     <map:action type="notify-admin"/>
>   </map:aspect>
> </map:aspects>

I don't like this and I don't see any reasonable use of the above 
system besides views. [c'mon, a logging aspect is much easier 
implemented by a different pipeline implementation, an admin-notifier 
is much better placed in a error-handler, where it belongs, and for 
flow-related actions, well, you know my opinion on those]

What am I missing?

> >
> With virtual pipelines (vp) we could as well do:
>
> <map:aspects>
>   <!-- if the "from-label" condition of the current pipeline component
>        matches "content", then insert right after it the virtual
>        pipeline called gather-links and content-view.
>        IOW add a link gatherer and a link view after each content
>        labeled component.-->
>   <map:aspect type="from-label" test="content" vp="gather-links"/>
>   <map:aspect type="from-label" test="content" vp="content-view"/>
>
>   <!-- if the "pipeline" condition of the current pipeline component
>        matches "start", then insert right after it the virtual
>        pipeline called check-security.
>        IOW add a security check at each pipeline start.-->
>   <map:aspect type="pipeline" test="start"  vp="check-security"/>
>
>   <!-- if the "pipeline" condition of the current pipeline component
>        matches "all", then insert right after it the virtual
>        pipeline called logger.
>        IOW add a logger after each component.-->
>   <map:aspect type="pipeline" test="all"  vp="logger"/>
>
>   <!-- if the "error" condition of the current pipeline component
>        matches "all", then insert right after it the virtual
>        pipeline called check-security.
>        IOW notify the admin when the error pipeline gets called.-->
>   <map:aspect type="error" test="all" vp="notify-admin"/>
>
> </map:aspects>
>
>
> Note that the virtual pipeline can also contain the call to the 
> flowscript, so I can effectively ask Cocoon to pass any condition to 
> the flow, and use it for more effective management.
>
>
> *IMPORTANT* (and the reason why I started the RT):
> So in he CLI, instead of asking for the link view and then generate, I 
> simply ask Cocoon to insert a transformer that gathers links in the 
> same positions where the links view would.
>
> This would make it possible for the CLI to have the configurability of 
> the view gatherer but the speed of the transfomer gatherer.

This is probably the point I'm missing.

Instead of discussion the solution, can't we start over again from the 
problem? maybe there are easier solutions that you didn't think about.

> What do others think?
>
> Is it already possible to do this today with other components and
> skillful pipeline writing?

what do you mean with "this"?

> For doing it at the beginning or at the end
> of a request it's possible to have an entry-point pieline that has pre
> and post processing, but to add stuff *inside* other pipelines? I think
> it cannot be done today.

Sorry, but I'm lost.

--
Stefano.