On Thu, 16 May 2002 03:11, Berin Loritsch wrote: > Question: > Is the ResourceAccessor able to be extended? There are container > resources that I would like to pass from one a parent container > to a child container.
Actually passing resources from parent to child containers is one of the reasons for this interface but I am not sure why that means it > > * utils to model metadata (if they can ever be abstracted well enough) > > We need a place to start. Lifestyle and dep/reqs are important > metainfo. A container can ignore the info that it doesn't support, > but if the meta info is there we can pull it dynamically in a > consistent manner. > > > * utils to enforce metadata model (like what is done in > > phoenix now with > > Proxies and all that) > > Kind of like a BlockInfo checker? Sorta. this object both checks metadata is valid, the component conforms to metadata and that the component is valid in context of applicaiton. ie * are names of components/dependencies are well formed * make sure component actually implements interfaces for particular roles it declares it implements * make sure that any required dependencies are actually present and implement required services * make sure that component is not used after it is stopped/disposed * make sure that component implementation can not be accessed (ie proxy component behind its work interfaces) * make sure versions of dependencies/implementations match * make sure that all required dependencies are extracted in compose/service methods * Allow component to declare requirements for data to be present in context * Make sure container extracts data from context in contextualize() * validate parameters/config against ParameterSchema, ConfigurationSchema ... ie the list can go on for ever. Some of these checks will just generate warninggs if you fail them while others will cause exceptions. Not all of the above checks will be implemented in all containers but you get the basic picture. > > However this assumes that I actually find an acceptable level > > of abstraction > > which I am not so sure of atm ;) > > I think the key pieces of MetaInfo for a Component are: > > * published interface (I.e. work interface). In Phoenix it is called > the "service". > > * interface version > > * lifestyle info (is it threadsafe?, what is the minimal instance > policy?) > > * requirements/optionals > > * implementation version What I have now is the following * component "shortname" * component "version" * component attributes (like lifestyle stuff) * Services the component exports * Services the component depends upon * Values that must be in context * Schema of Configuration/Parameters > The published interface is able to declare what the component > implements. > It is good design to only implement one interface--with the only > possible > exception being a compatibility layer (i.e. between different versions > of > a store interface). Or a Management version of same interface or perhaps separation between mutator version of interface and read-only version of interface. > The easy way to do it is to establish the creational policy, and give it > a > name: > > pooled - Pool of instances (one instance retrieved per request) > perthread - One instance per thread > factory - Create/destroy instance for each request--is this necessary? > Is the PerThread sufficient? > singleton - One instance to rule them all... One instance shared between > all threads/requests Oooer - I like that. I will break component attributes down into creation attributes and operational attributes -- Cheers, Peter Donald -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
