You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/04/10 16:45:56 UTC
ComponentManagement Infrastructure.
I want to alter the ComponentManagement infrastructure slightly.
I am changing it so that the DefaultComponentManager can be given
a RoleManager which is configured independently of the Component
Manager. That will allow us to place the Role mapping into a
separate file completely, and keep it as a developer concern.
I will also add one more method to the RoleManager interface so
that ComponentSelectors can query for default classes of a component
type with a shorthand name. This will ease the deployer's job
and not confuse them with too much information.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ComponentManagement Infrastructure.
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
>
> I want to alter the ComponentManagement infrastructure slightly.
> I am changing it so that the DefaultComponentManager can be given
> a RoleManager which is configured independently of the Component
> Manager. That will allow us to place the Role mapping into a
> separate file completely, and keep it as a developer concern.
This is done.
> I will also add one more method to the RoleManager interface so
> that ComponentSelectors can query for default classes of a component
> type with a shorthand name. This will ease the deployer's job
> and not confuse them with too much information.
This is done too.
An example of this working is in Cocoon with a "cocoon.roles" file.
that describes everything you need to know, and all is well with
the world.
NOTE: There is nothing saying you can't use a hardcoded RoleManager
class with the framework. We just have this one set up with an
XML configuration file.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ComponentManagement Infrastructure.
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Berin Loritsch <bl...@apache.org>:
> I want to alter the ComponentManagement infrastructure slightly.
> I am changing it so that the DefaultComponentManager can be given
> a RoleManager which is configured independently of the Component
> Manager. That will allow us to place the Role mapping into a
> separate file completely, and keep it as a developer concern.
+1
>
> I will also add one more method to the RoleManager interface so
> that ComponentSelectors can query for default classes of a component
> type with a shorthand name. This will ease the deployer's job
> and not confuse them with too much information.
+1
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: ComponentManagement Infrastructure.
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
>
> I want to alter the ComponentManagement infrastructure slightly.
> I am changing it so that the DefaultComponentManager can be given
> a RoleManager which is configured independently of the Component
> Manager. That will allow us to place the Role mapping into a
> separate file completely, and keep it as a developer concern.
This is done.
> I will also add one more method to the RoleManager interface so
> that ComponentSelectors can query for default classes of a component
> type with a shorthand name. This will ease the deployer's job
> and not confuse them with too much information.
This is done too.
An example of this working is in Cocoon with a "cocoon.roles" file.
that describes everything you need to know, and all is well with
the world.
NOTE: There is nothing saying you can't use a hardcoded RoleManager
class with the framework. We just have this one set up with an
XML configuration file.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org