> From: Peter Royal [mailto:[EMAIL PROTECTED]]
>
> .. and to take us back down to the reality of working code
> from the design
> discussions :)
>
> Berin, you mentioned something the other day about thoughts
> you had on the id
> attribute in fortress, might you want to expand?
>
> I'm thinking it might be cool to make the logger be the id
> attribute. It
> would make it nice and easy (imho) to have logical categories.
> -pete
Right now, the id="" attribute is used with two meanings:
* This is a component (i.e. config items without an id are skipped)
- Note: this is confusing when you think that a component should
load and it doesn't
* In the event that the Component is looked up through a selector,
the id is a hint
- Note: in XML all ids must be unique, so you can't reuse a hint
name even if it belongs to a different type of component
The logger category is driven off of a different attribute. The
"logger" attribute is used. That makes it easier to do things like
this:
<file-generator id="file" logger="generator.file">
.....
</file-generator>
<db-generator id="db" logger="generator.db">
....
</db-generator>
The design reason I had for doing this is that I wanted the Container
(if it so chose) to always return a default mapping of a role for
a lookup. (It defaults to the first component of a specified type,
which I think can be overridden with a default="true" attribute).
Taking advantage of the role idiom, the Container will return the
requested
component using the following logic:
1) Role name alone:
Return the default component
2) Role name + "Selector":
Return the component selector
3) Role name + "/extension":
Return the component matching the id
This allows developers who are migrating their component systems to
more intelligent mapping to still be able to use their legacy
components.
For example, in Cocoon many of the components that use a database assume
there is a ComponentSelector between them and the DB. With the
AbstractContainer logic, the legacy components will still work--but
components that just want to get the default database will be able
to look it up by the simple role name.
It also simplifies things so that instead of two containers (ECM/ECS)
to manage the relationships, there is only one which makes it easier
to manage all the components in a system.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
