Nicola Ken Barozzi wrote:
>
>
> 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 ;-)
I know - but for me its clear - you supply services via a service
manager - String, File and ClassLoader are not services (and here I'm
using the term "service" to describe something that is versioned, can
expose multiple interfaces potentially as proxied references, may have
depednecies, etc.).
>
>>> 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.
Desirable but probably not enforeable.
>
>
> 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>
Exactly!!
>
> BTW, what the heck is Cocoon from an architectural POV?
> A service? A container? Both?
No idea - I don't use Cocoon and have never had the occasion to get into
it in more detail..
>
>
> 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 agree.
>
>
> 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)?
>
I would take the second approach - expose kernel services as standard
services.
Cheers, Steve.
--
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]>
