Return-Path: 
 <dev-return-73260-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 48769 invoked from network); 13 Apr 2005 13:14:10 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 13 Apr 2005 13:14:10 -0000
Received: (qmail 47490 invoked by uid 500); 13 Apr 2005 13:14:03 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 47403 invoked by uid 500); 13 Apr 2005 13:14:01 -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 47375 invoked by uid 99); 13 Apr 2005 13:14:01 -0000
X-ASF-Spam-Status: No, hits=-10.0 required=10.0
	tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from minotaur.apache.org (HELO minotaur.apache.org)
 (209.237.227.194)
  by apache.org (qpsmtpd/0.28) with SMTP; Wed, 13 Apr 2005 06:13:57 -0700
Received: (qmail 48400 invoked from network); 13 Apr 2005 13:13:56 -0000
Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1)
  by 127.0.0.1 with SMTP; 13 Apr 2005 13:13:56 -0000
Message-ID: <425D1B51.4070100@apache.org>
Date: Wed, 13 Apr 2005 15:14:57 +0200
From: Carsten Ziegeler <cziegeler@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Directory structure of blocks
References: <20050409083134.46541.qmail@minotaur.apache.org>
 <425A36D5.4010809@nada.kth.se> <425A3A7B.5030203@apache.org>
 <425A6B42.1040009@nada.kth.se> <425A7094.8040906@apache.org>
 <425A8A7A.1030203@nada.kth.se> <425A8EAF.7090502@apache.org>
 <255a9c1e1ee0934507a1f5447f3ef066@betaversion.org>
 <425BDF4B.8040705@apache.org>
 <3e1766b0f6774aa2f9b7a26a729043ae@betaversion.org>
In-Reply-To: <3e1766b0f6774aa2f9b7a26a729043ae@betaversion.org>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Rating: 127.0.0.1 1.6.2 0/1000/N
X-Virus-Checked: Checked
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Pier Fumagalli wrote:

> 
> <SNIP/>
>
> If on the other hand we separate entirely components and java code from 
> blocks, the implementation becomes _much_ more easy...
> 
> My idea would be that a block (for example, our ForrestSkin 
> implementation) _requires_ a component (not a block) that performs XSLT 
> transformations.
> 
> Requiring this, it will expose (for example) a "Virtual Transformer" 
> called "document2html" which will be implemented as XSLT Transformer + 
> document2html.xslt.
> 
> Another skin for forrest could (at the same time), implement the same 
> interface and provide the same "document2html" transformer by requiring 
> the STX transformer and "joining it up" with "document2html.stx".
> 
>  From outside, the two blocks _both_ provide a transformer, which does 
> exactly the same job, but rely on the component manager underneath to 
> solve the class loading problem of providing a component with a given 
> role, add their value to it (the XSLT, STX, ... stylesheet) and expose 
> it to the users of the implemented interface.
> 
> And this frees up the blocks implementation from the underlying 
> component management, java, class loaders and so on... I feel this a 
> lot more cleaner in terms of separating the concerns of cocoon and 
> blocks versus the concerns of the Java platform and its classloading 
> cumbersomeness...
> 
Where do the components life and where are they defined?

I'm not sure if I totally understood everything discusses so far, but
imho we need some versioning: we recently had the following problem. In
a cocoon application we used Hibernate that requires the version 1.4.x
of the asm jar file. With Cocoon 2.1.7 we ship version 1.5.x which
causes some method not found exceptions inside hibernate :( Ok, now we
could lean back and blame the developers of asm creating incompatible
versions, but I think this is a general issue. What if one component
requires version 2.x of a third party lib while another one requires a
1.x version. Etc.
Fortunately, we could solve this problem in our solution by just using
asm 1.4.x as we don't need the BSF block.

Ok, long story, short question: do we plan to support such scenaries
with real blocks? I really hope so :)


Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/