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? -- 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]>
