Paul Hammant wrote:
> Nicola,
...
>> So you are saying that the Phoenix BlockContext has to be regarded as
>> the standard Container Context?
>
> Yup, it seems that the multi-year-old BlockContext is part of a defacto
> API.
Aha! :-))
Finally you say it. You keep going in circles around it, and finally I
make you say it.
*This* is the whole point in this contention.
So, you see that for you Phoenix is the Avalon RI!
> If you look at phoenix-client.jar you'll see that it is quite
> small and given amazing accident or far-sighted design by Stefano/Fede
> and others marks a good division between interface and impl of Phoenix
> from the component writers point of view.
>
> Yes, it has the word phoenix in it, but as I have pointed out before
> does not mean that all of Phoenix has to be included. It is already a
> better interface/impl separation than Sun's JMX or Servlet APIs are
> which require forking by alternative container developers.
Good, then let's define it standard, and move it to Excalibur, with a
*combined* effort, not a silent "let's dump it there and others adopt
the de-facto standard"!
It's the *same* thing Stephen is saying, man, why the heck do you think
he put the work "Generic" in his version?
Container must only depend on framework, not on other Containers.
Containers can be used hierarchically during runtime, but not depend on
parts of other containers.
I'm against de-facto standards becoming *silently* standards.
This way of declaring Phoenix features "standard" without discussion has
upset some developers, and has created FUD.
You see, you couldn't even say it clearly yourself!
>> This I understand, and I would like to see it become part of the
>> containerkit somehow or of the framework if this is the case.
>>
>> Don't ask me why, it's obvious.
>
>
> Apart from backards compatability. Yes, I might agree to a move to A-F.
> No, I might agree that it we had our design time again, we'd have a
> hierarchy (or not) of Context in A-F. A move to containerkit is not
> going to please the Merlin folks as they are based on
> excalibur/container.
Excalibur/container and ContainerKit are efforts to redefine in a more
generic solution.
It's design time, man.
...
--
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]>
