Return-Path: 
 <dev-return-49263-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 36599 invoked from network); 12 Oct 2003 16:59:59 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 12 Oct 2003 16:59:59 -0000
Received: (qmail 839 invoked by uid 500); 12 Oct 2003 16:59:47 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 791 invoked by uid 500); 12 Oct 2003 16:59:47 -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 770 invoked from network); 12 Oct 2003 16:59:46 -0000
Received: from unknown (HELO pulse.betaversion.org) (217.158.110.65)
  by daedalus.apache.org with SMTP; 12 Oct 2003 16:59:46 -0000
Received: (qmail 28277 invoked from network); 12 Oct 2003 16:59:47 -0000
Received: from unknown (HELO apache.org) (stefano@80.105.91.155)
  by pulse.betaversion.org with SMTP; 12 Oct 2003 16:59:47 -0000
Date: Sun, 12 Oct 2003 18:59:51 +0200
Subject: Re: [RT] Component manager, classloader and blocks
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: <Pine.LNX.4.44.0310121200580.11811-100000@vern.chem.tu-berlin.de>
Message-Id: <7E73EB7D-FCD5-11D7-B7DA-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 Sunday, Oct 12, 2003, at 12:21 Europe/Rome, Stephan Michels wrote:

>
>
> On Fri, 10 Oct 2003, Stefano Mazzocchi wrote:
>
>>
>> On Friday, Oct 10, 2003, at 13:22 Europe/Rome, Stephan Michels wrote:
>>
>>> To prevent component name collisions within, we could use prefixes 
>>> like
>>>
>>>  <match type="basic:wildcard" pattern="*.html"
>>>   <map:generate type="basic:file" src="{1}.xml"/>
>>>   <map:transform type="basic:xsl" src="mystyles.xsl"/>
>>>   <map:transform type="mytransformer"/>
>>>   <map:serialze type="basic:html"/>
>>
>> name collision of what? you define the names of the components. those
>> are the prefixes already, the classes are the real names of the
>> components and they are already fully qualified to avoid collisions.
>
> Okay, I think you mean, (for example) if you want to use a generator 
> from
> block 'basic', you can write easly
>
> myblock:sitemap.xmap:
> <map:components>
>  <map:generators>
>   <map:generator name="file" src="basic.BasicGenerator"/>
>
> But in this case you doesn't gain anything more than from avalon block.
> I want to share these components by the @type insteadof the class name.
>
> For example virtual components can only be shared with @name/@type
> names.
>
> Now, if you a block, which depends on block, which shares
> components with the same type, you will have conflict.
>
> One possible solution is to use prefixes, which allow to map names
> to block IDs.

hmm, I don't think these conflicts are a problem since it's *you* that 
name the components with hints, not the block that exposes them.

>>> For the classes and libs itself, I think separate them into public
>>> and private isn't necessary for the first step.
>>
>> Either we do this right away or it's going to be painful later on. I
>> would be against such an half-step (also because classloading
>> complexity isn't that much different with the two paths)
>
> Here we do have different opinions. I'm curious about the opinions
> from the others.
>
> One question, separate the avalon block the classes into 
> public/private?
>
> Stephan.
>
>
>
--
Stefano.