cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: AW: [C2]: Avalon Component Configuration
Date Tue, 10 Apr 2001 15:00:46 GMT
Quoting Berin Loritsch <>:

> Giacomo Pati wrote:
> > 
> > Quoting Carsten Ziegeler <>:
> > 
> > I can now answer this myself. No, it is not sufficent to define a role
> element
> > for a component. There needs to be a component definition.
> See my response to this.  The ComponentManager has always been able to
> do this
> after my introduction of the shorthand name concept for the
> configuration
> file.  Basically you just accept the defaults, and an empty
> Configuration
> object is passed to Configurable components that are not declared
> explicitly.
> > > And the lookup of the components is done via the role name, correct?
> > > So, looking up "org.apache.cocoon.components.url.URLFactory" would
> > > work. Would it be also sufficient to lookup "url-factory"?
> > 
> > No, it needs to be the working interface name (the value of the name
> attribute
> > of the <role> element or the value of the role attribute of the
> <component>
> > element). I don't know if this could be an enhancement to the
> ComponentManager
> > system to lookup shorthands as well. Berin?
> I would strongly recommend not to do this.  We spent alot of time on
> the Avalon project comming up with reasons for and against this.  The
> bottom line is that the Contract with a Role has to be strong.  It
> should
> not be weekened by aliases in the component management framework. 
> Otherwise,
> what would happen is your code would break as soon as you changed the
> shorthand name for the Component.
> We came up with the standard of following interface names to avoid
> name claches in environments where Components are developed by various
> companies.  With that tight coupling, you can be reasonably assured
> that the Component instance retrieved from the ComponentManager
> implements
> the API you depend on.  We do allow for deviations in two cases:
> ComponentSelectors and Roles that share an interface but not a purpose.
> ComponentSelectors follow the pattern of the interface name with
> "Selector" appended to the end (e.g.
> "org.apache.cocoon.serializers.SerializerSelector").
> Roles that share an interface but a different purpose are still distinct
> roles.  Therefore, the role name needs to remain as close to the
> interface
> name as possible, but you may deviate on where the Class name *would*
> be.  Note: in cases where there is more than one interface in a package,
> you should append the diviation to the full interface name.
> > > I am asking this, because I want to use the Store for storing the
> > > cached content. This would allow to use existing interfaces and
> > > implementations for the caching.
> > > But I don't want to use the normal <store> component but an explicit
> > > Store for the caching which might have another implementation.
> > > Is this possible?
> > 
> > You have to use a ComponentSelector as component implementation in
> this case.
> > With the Selector one is able to get a specific implementation by use
> of a
> > "hint" (see datasources).
> Not necessarily.  They do not share the same ROLE.  A Role is not just
> an
> interface, but a component with a specific purpose.  SitemapComponents
> are
> accessed by ComponentSelectors because they share the same interface and
> purpose.  The same applies to the other instances we use
> ComponentSelectors.
> We already use a divergent Role name with the Store interface because
> the
> Repository and the Store roles have distinct purpose--but share the same
> interface.
> > > I know, I could create another Interface, like XMLStore, which
> > > extends Store and implement that - but then I could not use any
> > > Store implementation for caching. An own (inheriting) implementation
> > > is required to implement the XMLStore interface.
> > 
> > I thought the Store is an object store but the cache store is
> something that
> > keeps "compiled" SAX events. i don't know if setting up a different
> XMLStore
> > will suit better.
> I wouldn't.  Use the Store interface if it works for your purpose.  Use
> the role name "" for that
> purpose.

Ok :) you have convinced me for all issues.

Thanks for your clarifications.


To unsubscribe, e-mail:
For additional commands, email:

View raw message