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,
Many are deprecated, and Peter has clearly said he is moving to an
improved component model... which I think is even better BTW :-)
>> 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).
Hmmm...
>> 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.
All in one? :-?
>> 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).
You mean that in contextualize(), the context I get will be castable to
any of the above or that the container gives the appropriate context to
the appropriate component?
Ok, probably the case is the latter.
From containerkit:
<context type="MyContextInterface">
<entry key="base" type="java.io.File"/>
<entry key="mode" type="java.lang.Object" optional="TRUE"/>
</context>
I'm cool with it :-)
>> 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.
It's not a problem.
But since many things from there have somewhat landed in containerkit, I
was asking myself if it could go in excalibur as a common block; Phoenix
might have his own context that extends it still, but maybe it's time we
push it to a "standard" that is not only de-facto.
>> 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
Naaa, we can discuss on this too without fear, also since containerkit
already has the notion of a context desctiption.
> Other containers *can* be compatible with BlockContext, it is not tied
> to the Phoenix impl, it is reimplementable.
Ok, yes, ja, oui, it's true.
BlockContext is part of a Phoenix API, and is reimplementable and usable
outside of the Phoenix implementation.
>> 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. It would work as a strategy, 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.
Paul, it's not about not wanting Phoenix imports.
It's about opportunity.
The opportunity to officially push defacto standards that are useful to
a real Avalon standard.
If I want to use httpclient, I use httpclient. In your line of
reasoning, I should have used slide-client.
There is a reason why it was put in commons, and the same reason applies
to phoenix-client, well much of it.
Peter has made his view on the "common" stuff quite clear, and
containerkit is the right direction.
Think about this in that perspective.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
