Paul Hammant wrote:
> Nicola,
>
>>>> There is now 2 -1s on BlockContext.
>>>
>>>
>>>
>>>
>>> I like BlockContext. +1
>>>
>>> ( By my reckoning you are now at only -1 )
>>
>>
>>
>> Naa, he withdrew them.
>
>
> Yup bloody partially threaded mail (poor substiture for NNTP).
>
>> Paul, it's not about what I like or what you like or what John Doe
>> likes.
>> BlockContext is a dependency to Phoenix, and *if* we want to make
>> cross-container compatible components, it's not a solution.
>
>
> BlockContext is a dependancy to Phoenix's hosted compoent API
> (phoenix-client.jar). You do not need the rest of Phoenix to mount
> blocks. It is easy to be compatible,
>
>> It binds you to Phoenix, but I assume that it's not a problem for
>> you, you also made a GUI in Phoenix, so I understand you don't see
>> the point.
>
>
> It does not bind you to phoenix per se. It binds you to the small
> redistrubitable phoenix-client.jar and the classes it contains. This
> is true interface/impl separated API, and not a 'blessed' API like
> Sun's Servlet or JMX (and other I presume).
True.
And today with Phoenix as is - it defines a variant of a the Avalon
Component Model. That's ok providing the users of the API understand
the implications of coding against a container specific API. Those
implications are generally bad and should be documeted as
"not-best-practice".
>
>> But Avalon is not only Phoenix, and as Peter pointed out he would
>> like to be able to use Cocoon components.
>> I would like to use Phoenix components.
>
>
> There is no reason that a container could not afford a contextualize()
> that supports castability to BlockContext, CocoonContext, FooContext
> and BarContext.
Only if (a) you have a meta-info model in place that declares the
context derivative, and (b) the derivatibve implementation documents its
contract relative to the pure Context interface. Without those two
things in-place there is one good reason - your component will not run
outside of the Phoinix environment.
>
>> If I make the Cocoon components dependent on CocoonContext, it would
>> not make reuse by Phoenix possible.
>
>
> Maybe an kernel extended Phoenix could support CocoonContext and
> BlockContext (see above).
I think that is the wrong way to look at the problem. User's should not
be consered with "workarounds" - that should be able to build and deploy
components without concern for the containerment environment. In the
rare cases where something additional is needed, a good container will
provide plug-in mechanisms that provide a means for extension of the
container. In the long term its possible for such containement
extensions to become standard - but only with the emergence of several
different contains and a vested interest by respective champions to
achieve a common platform. Out there in the real world there are clear
economic reasons for doing that - in the open-source world things are a
lot more gray.
>
>> Think about this, instead of just saying "I like it".
>
>
> You unfairly trivialize my posting.
>
>> Let me be more clear if I can: Phoenix has a specific Context that it
>> only can use. It's needed, regardless to how itthere; it's needed,
>> and from a functionality POV I like it too.
>
>
> You make your case well. You are wrong that it is the only container
> than can use the years old BlockContext. I have outlined a number of
> times ways that aloternate containers can be compatible with
> BlockContext. The committer have taken a vote on the recommendation
> that phoenix-client.jar be considered the way that these alternate
> containers be compatible with BlockContext. I really don't see where
> the problem is.
Phonieix today does not provide any support for context declaration
which means Phoenix depedency components are locked into (a) using the
client jar file AND providing an alternative implemetation of
BlockContext. Paul - that's a big "AND" that I think you may have
forgotten about. Every addition to the BlockContext interface is
another problem to be dealt with. The practicle solution is for other
container to fall-back to common denominator position - the Avalon
Framework - Context interface. This at least places the responsibility
onto component authors to be careful about containment depedencies.
>
>
>> So the thing should be dealt with on two levels, which we are doing:
>>
>> 1) define common attributes and possibly common Context keys to
>> access common functionality
>>
>> - thus we need to have a simp�le way of telling in the descriptor
>> what Context is needed.
>
>
> Personally I am only willing to get embroiled in an attributes
> discussion if you will cede to and honor a simple often repeated point
>
> Other containers *can* be compatible with BlockContext, it is not
> tied to the Phoenix impl, it is reimplementable.
Sure - and I could join the Republican Party - but is it a good idea?.
;-)
>
>> 2) provide a "standard" implementation for "standard" containers of
>> concrete implementations of the framework, which is Containerkit.
>>
>> - Now it seems to me that BlockContext would be an excellent
>> candidate for the containerkit Context.
>> I would humbly propose to maybe put the BlockContext in containerkit,
>> deprecate the one in Phoenix, make the Phoenix one extend the
>> containerkit one for compatibility, and make Cornestone blocks, which
>> IIUC Peter also would like to see a components in excalibur (or
>> something like that), use the containerkit context.
>
>
> This is perfectly possible.
Anything is possible.
> It would work as a strategy,
A strategy towards what objective ?
With the seperation of the meta-info content from containerkit -
containerkit is just another container API that will probably end up
inside Phoenix.
> It might please people who don't want any phoenix package imports in
> their components. However, there is no proven need for it given the
> fact that phoenix-client.jar is usable by alternative containers.
Providing every other container provides the implemetations for Phonix
specific stuff - can someone explain to me why this is good thing?
Steve.
>
> - Paul
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
