cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Lewis" <...@ascii27.net>
Subject Re: Separation to Phoenix and Avalon 5 [was Re: [RT] Cocoon Blocks]
Date Wed, 03 Jul 2002 01:41:24 GMT

Thanks...got it...I think.

I'll be interested to hear how the research comes out....


> Andy Lewis wrote:
>
>> If I have a custom transformer or generator that I wanted to deploy as a part of
Coccon block,
>> can I using that interface? And is it an Avalon component or not? Are there adidtional
steps
>> beyond just making it a cocoon block?
>
> Sitemap components follow the avalon lifecycles but aren't exactly 'avalon components'
because
> they are intrinsically tight to the cocoon interfaces.
>
> The question you should ask yourself when deciding if something is an avalon component
is:
>
>  can I deploy my component in another avalon container? (say, Phoenix?)
>
> If you look into org.apache.cocoon.components many of them are avalon components that
could be
> ported to other containers (even the
> 'programminglanguage' component, the core of the XSP engine, could be decoupled from
Cocoon and
> used elsewhere).
>
> But a 'sitemap component', by design, isn't portable.
>
> Also, another difference is that while avalon components are accessed by role (thus behavior)
> and it's the container's concern to look it up, sitemap components are accessed by both
role
> and hint, thus it is *not* the container's concern to look up the class (its concern
is only to
> map the hint to the classname, but control is re-inverted back).
>
> On avalon-dev we had a pretty serious (and painful) discussion about this and it has
been
> suggested that Cocoon has been using Avalon for its lifecycle (configurable, loggable,
etc..)
> more than for its inverted lookup capabilities. So Avalon has been used *and* abused
by this
> project.
>
> Used for moveable components and abused for those cocoon-specific
> components.
>
> This said, it becomes obvious why we need two different deployment mechanism: one for
generic
> avalon components (think of Parsers, XSLT Processors, Source Resolvers, Code Producers,
etc..),
> and another for cocoon-specific stuff (think of a web mail, a skin, a shopping cart,
etc..).
>
> The question was: even if these two things are different and live in two different
> architectural layers, could the same code be used to implement both?
>
> I've spent some time investigating this and I don't think Phoenix is up to the job, because
it
> is more biased toward having a single instance per JVM.
>
> Now I'm looking at Fortress and Merlin as possible future candidates.
>
> I'll report back when I'm done.
>
> Stefano.
>
>
>
> --------------------------------------------------------------------- To unsubscribe,
e-mail:
> cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org


-- 
"The heights of genius are only measurable by the depths of stupidity."



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message