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)
In this, we find *services* that are of the Cocoon container:
URL getResource(String path) throws MalformedURLException;
String getRealPath(String path);
String getMimeType(String file);
InputStream getResourceAsStream(String path);
So a Context now generally contains:
- Avalon container live values
- Avalon container services
- Cocoon container live values
- Cocoon container services
<ugh>
--
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]>
