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). > 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. > 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). > 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. > 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. > 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 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
