Return-Path: 
 <cocoon-dev-return-19801-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 53353 invoked by uid 500); 11 Dec 2001 21:16:34 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 53338 invoked from network); 11 Dec 2001 21:16:33 -0000
Message-ID: <3C165C31.E648C06B@apache.org>
Date: Tue, 11 Dec 2001 20:19:13 +0100
From: Stefano Mazzocchi <stefano@apache.org>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Managing Flow and Resources
References: <200112102211.fBAMBnU20988@orion.rgv.hp.com>
 <3C16124A.DC33B7BC@apache.org> <005f01c1826a$866a4420$670004c0@PC103>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Nicola Ken Barozzi wrote:
> 
> ----- Original Message -----
> From: "Stefano Mazzocchi" <stefano@apache.org>
> To: <cocoon-dev@xml.apache.org>
> Sent: Tuesday, December 11, 2001 3:03 PM
> Subject: Re: [RT] Managing Flow and Resources
> 
> <snip/>
> 
> > I think you are oversimplifying: I agree with you that actions and
> > action-sets are something that should not be in the sitemap (I always
> > found strident the different degree of reuse you had with pipeline
> > components and actions), but at the same time, the current sitemap
> > semantics is IMO very well designed for stateless publishing needs,
> > which still are the great majority of the web resources.
> 
> IMO Actions are needed in the pipeline.
> Sometimes you want to apply actions to a whole "class" of pipelines,
> not only to the current flowing "instances".

When I say SoC between 'sitemap' and 'flowmap', I don't necessarely mean
that you have to call a flowmap from a sitemap and stop there.

In fact, it could be possible, to 'mount' a sub-sitemap to a flowmap. 

In this case, you could 'wrap' your sub-sitemap with some
flow-describing code that, for example, might manage access rights,
authentication or stuff like that.

Once we have separated the concerns, it's up to you to 'compose' them in
the best way and I think that if sitemaps can mount flowmaps and
flowmaps can mount sitemaps, the balance is achieved and actions can be
removed from the sitemap.

> For example, for access control or single routine db actions they
> are good.
> The problem arises when the interaction is more complex than
>  a simple request-response.
> Sessions take care of the data part, flowmaps or such should
> take care of the flow part.

No, I picture sitemaps defining stateless activity and flowmaps stateful
activity.

I know it's a rather unusual way of thinking at web programming, but I
have the feeling there is incredible usefulness in this approach, since
change or reusing those *maps increase substantially the more separate
their concerns are kept.

[NOTE: Access control *is* a stateful activity, almost by definition:
browsers keep on sending the user/password pair to keep the state]

-- 
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