Stephen McConnell wrote:
...
>> Context is a very delicate point in the context ;-) of component
>> portability.
>>
>> Personally I tend to think (sensation) that the whole concept of
>> Context is flawed, because it is usually used in the wrong way.
>>
>> Services can be given by the ServiceManager. The container should
>> *never* expose itself to the components it manages, it breaks SoC and
>> IoC. This means that the abuve services you mention should not be
>> given at all to the component, given as a service or given in a
>> standard way that we should define.
>
> This is the issue - "given as a service or given in a standard way that
> we should define" - we know how to create components - we have to define
> the standard way of creating context.
+1
>> I think that Context is a hole in the whole architectire.
>>
>> What cases can *only* be /reasonably/ solved by a Context?
>
> String name = (String) context.get("name");
> File rootDir = (File) context.get("root");
> ClassLoader loader = (ClassLoader) context.get("classloader");
String name = (String) servicemanager.get("name");
File rootDir = (File) servicemanager.get("root");
ClassLoader loader = (ClassLoader) servicemanager.get("classloader");
Go tell users the difference ;-)
>> How can we try to enforce good use of it?
>
> By providing a specification of how context values can be created. That
> specification then defines the limitation a developer can work within to
> ensure component context usage is not tied to a particular container.
+1
And keep kernel services out of there somehow.
Since Cocoon *will* have his context, if we put kernel access stuff in
there too we will have a context with a double container dependency <ugh>
BTW, what the heck is Cocoon from an architectural POV?
A service? A container? Both?
I see two types of components in Cocoon: generic ones, that will be made
as the new block specification, and Cocoon specific ones, the sitemap
components.
The latter will need to rely on a CocoonContext, the others won't.
If Cocoon wants to access the kernel services IMO it should not go
through CocoonContext, but via a KernelService or whatever.
I understand that exposing the kernel as a service has created problems,
but can't we:
- take it away from context without putting it in service (ie new method)
or
- expose the kernel services as generic standard services based on the
container profile (micro, std, ee)?
--
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]>
