Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
From: "Leo Sutic" <leo.sutic@inspireinfrastructure.com>
To: <dev@cocoon.apache.org>
Subject: RE: [Kernel22] How to develop a component?
Date: Wed, 7 Apr 2004 12:34:36 +0200
Message-ID: <022101c41c8b$ed1959f0$0801a8c0@lagrange>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <40732D5C.9040605@apache.org>


> From: Stefano Mazzocchi [mailto:stefano@apache.org] 
>
> So, like we already said before, it is *totally* possible to have a 
> block load avalon components thru an avalon sandbox (sort of a 
> avalon->cocoon adapter). This allows you to reuse your avalon 
> stuff "AS IS". But this also means that your block cannot expose those

> components outside of that block.

I don't think so.

The fact that Avalon doesn't support hotswap in all cases does 
not mean that you can't write Avalon components that do support
such a thing.

Look at Composer.acquire() - does it matter if the object
returned is a proxy to some internal Avalon object? No!

You can have:

 +Block-------------------------------------------+
 |                             +-+Component       |
 |  +Composer--+    +ECM----+  |                  |
 |  |          |----|       |--+-+Component       |
 |  +----------+    +-------+  |                  |
 |                             +-+Component       |
 +------------------------------------------------+

And then expose the components managed by the ECM via a proxy.
However, those components must either:

 ...be written in such a way as to support the additional 
    requirements that Cocoon has

 ...or have that functionality added via proxying etc.

So I think Carsten's (and my) business logic, and all our Avalon
components that we use across multiple projects and containers
are perfectly safe.

/LS