Nicola Ken Barozzi wrote:
>
> Stephen McConnell wrote:
>
>>
>>
>> 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.
>
>
> ;-) Yeah.
>
>> 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.
>
>
> Ok, I like this :-)
>
> Just one more question: how about the stuff that Cocoon Components use
> to get info about the request, the response, etc...
>
> How do you think Cocoon should supply them?
>
I must confess that I'm not real up-to-date on the latest spec for
"stuff" ;-) - could you expand a lttle bit please (keeping in mind my
very limited knowledge of Cocoon). Also - to what is a request being
directed?
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]>
