Return-Path: 
 <cocoon-dev-return-22378-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 59974 invoked by uid 500); 7 Feb 2002 00:03:15 -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 59963 invoked from network); 7 Feb 2002 00:03:14 -0000
Message-ID: <3C61C446.B45DA1C7@apache.org>
Date: Thu, 07 Feb 2002 01:03:18 +0100
From: Stefano Mazzocchi <stefano@apache.org>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Componentizing Cocoon Applications
References: <3C5D5893.7499B8DB@apache.org>
 <20020206062711.21FFE23D9B@dj.codeconsult.ch> <3C6119EE.4A7AC4BF@apache.org>
 <20020206204852.3F2CC23D9B@dj.codeconsult.ch>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Bertrand Delacretaz wrote:
> 
> On Wednesday 06 February 2002 12:56, Stefano Mazzocchi wrote:
> >. . .
> >  <transform src="[news]:[rss]->[document].[xslt]/no-abstract"/>
> >  <transform src="[structure]:[layout]->[document].[xslt]"/>
> >  <transform src="[skin]:[document]->[fo].[xslt]/A4/with-index"/>
> 
> This looks ugly (or is it just me?) which is usually not a good sign ;-)
> 
> >. . .
> > The same functionality can be done eliminating this further address
> > space by taking the internal component file space and mapping it
> > one2one with the contract:
> >
> >  <transform src="[news]://adaptors/rss2document/no-abstract.xslt"/>
> >  <transform src="[structure]://adaptors/layout2document.xslt"/>
> >  <transform
> > src="[skin]://stylesheets/document2fo/A4/with-index.xsl"/>
> >. . .
> 
> Yes, I agree here - not enforcing all contracts at the [virtual
> protocol] level, but having additional subcontracts more loosely
> defined at a second level, did I get it right?
> 
> Looks at lot like polymorphism to me: considering no-abstract.xslt as
> an object of its "superclass" [news:]//adaptors/rss2document without
> caring about the details.

Exactly!!!

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