Nicola Ken Barozzi wrote:
>
> Leo Sutic wrote:
>
>>
>>> From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>>
> ...
>
>>> This is where the separation occurs between metainfo (the
>>> constraints) and metadata (the criteria). If we have a context
>>> constraint that says that the context must container an entry called
>>> "home" and that the value returned shall be a java.io.File and that
>>> it contains an entry called "name" and that the type is
>>> java.lang.String - I can declare this in an xinfo as follows:
>>>
>>> <component-info>
>>> <context>
>>> <entry key="home" type="java.io.File"/>
>>> <entry key="name" type="java.lang.String"/>
>>> </context>
>>> </component-info>
>>>
>>> The next issue concerns the responsibility of the container to
>>> fulfil that constraint. To do this a directive is needed in the
>>> component desciption. For example the following information could be
>>> included in a application profile:
>>>
>>> <component class="net.osm.test.MyComponent" name="test"> <context>
>>> <entry key="name" value="Fred"/> <entry key="home"
>>> class="java.io.File" value="../myHome"/> </context> </component>
>>>
>>> In this simple example a single String argument is being supplied.
>>> The class must have a constructor that takes a single string value
>>> as a parameter. For example - the case of java.io.File - it has a
>>> constructor that can support the above. In the case of the name
>>> (where the default type is String), the String class also contains a
>>> constructor with a single String parameter. My experience with
>>> automated context value creation is that single string parameter
>>> constructors resolved using reflection solve 98% of the
>>> requirements. However, there are cases when you want to go further
>>> than this and provide multiple parameters to the class constructor.
>>
>>
>>
>> This would indicate that all values in the component
>> context are supplied by the assembler (the person creating the
>> component config).
>>
>> My question was regarding container-supplied context values.
>>
>> It would appear that context values entered as you describe
>> are limited to:
>>
>> + constants
>>
>> + entered by a human
>>
>> Is this correct?
>>
>> I would then propose that we define a fixed set of context keys
>> that the *container* must supply (and some that it may supply).
>>
>> For example, the context directory may be given by a servlet
>> container and should only be passed on to the components by the
>> containers.
>
>
> To be concrete, this is the Cocoon Context:
>
> public interface Context {
>
> Object getAttribute(String name);
> void setAttribute(String name, Object value);
> void removeAttribute(String name);
> Enumeration getAttributeNames();
> URL getResource(String path) throws MalformedURLException;
> String getRealPath(String path);
> String getMimeType(String file);
> String getInitParameter(String name);
> InputStream getResourceAsStream(String path);
> }
>
> As you see:
> 1. it doesn't extend avalon Context
> 2. it's gotten from the avalon context as an object via a key (ie one
> key to get the context, one to get the actual parameter)
I'll ignore the fact that the above interface is unfortunately named
Context and consider this just an interface to a java Object which is
exposed in an avalon Context instance. The more import criteria
relative to this thread is how an instance can be created. I would like
to dig a little into this example and demonstrate how a component can
declare, validate and instantiate a context containing an object
implementing the above interface.
First of all - we have the declaration by the componet type that it
needs to be supplied with a (Avalon) Context instance that contains an
object that implements the (Cocoon) Context interface.
<component-info>
<context>
<entry key="cocoon-context" type="somewhere.cocoon.Context"/>
</context>
</component-info>
The next issue concerns the declaration of the criteria for the creation
of the context object (assuming that we are building a portable
component). The following enty is an example based on the existing
ContextFactory appraoch.
<component name="cocoon-thing"
class="somewhere.cocoon.CocoonRelatedComponent".>
<context>
<entry name="cocoon-context
class="somewhere.cocoon.DefaultCocoonContext">
<param name="url"
value="http://somewhere.something/value.whatever"/>
<param name="mime" value="a-mime-value"/>
<param name="mime" value="a-mime-value"/>
<param name="init-params"
value="initial-params.properties" class="java.io.File"/>
<param name="attributes" value="attributes.properties"
class="java.io.File"/>
</entry>
</context>
</component>
Given the above example - ContextFactory (one example of declarative
context management) creates a new instance of DefaultCocoonContext using
the 5 parameters as constructor arguments. The resulting object is then
added to the context map under the key "cocoon-thing". Using the above,
the cocoon component that need a context object as descibed, can now be
portable - i.e. it can be deployed independently of the container - it
can still be managed inside a system programatically but it also has the
full declaration of how it can be managed outside of a cocoon specific
environment and independent of a specific container.
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]>
