You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Christian Heller <ch...@tuxtax.de> on 2002/02/03 16:16:06 UTC
Pairs of concerns
Hi,
I miss the counterparts of some methods in your Framework. For example,
the Configurable should get not only a method "configure" but also a method
"deconfigure" (or "unconfigure", I'm not so good in English). The same for
method "compose" which should get a counterpart "decompose" etc. In general,
I guess that all methods should appear in pairs.
Explanation:
When I execute/run an application ("component"), it gets configured. In its
lifetime, the user may change several settings. When the component is shut
down, the new settings will have to be stored into the configuration file or
database or whatever. So, a method "deconfigure" could be useful.
Regards,
Christian
--
http://www.resmedicinae.org
- Information in Medicine -
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Pairs of concerns
Posted by Berin Loritsch <bl...@apache.org>.
Christian Heller wrote:
> Hi,
>
> I miss the counterparts of some methods in your Framework. For example,
> the Configurable should get not only a method "configure" but also a method
> "deconfigure" (or "unconfigure", I'm not so good in English). The same for
> method "compose" which should get a counterpart "decompose" etc. In general,
> I guess that all methods should appear in pairs.
>
> Explanation:
> When I execute/run an application ("component"), it gets configured. In its
> lifetime, the user may change several settings. When the component is shut
> down, the new settings will have to be stored into the configuration file or
> database or whatever. So, a method "deconfigure" could be useful.
Understood, and I am working on something that handles the Configuration
aspect. Deconfigure or Unconfigure is not the right word though.
As to the opposite of Compose, there is none, so don't try to force it.
----------------------------------------------------
Sign Up for NetZero Platinum Today
Only $9.95 per month!
http://my.netzero.net/s/signup?r=platinum&refcd=PT97
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Pairs of concerns + HMVC Components?
Posted by Berin Loritsch <bl...@apache.org>.
Christian Heller wrote:
> On Monday 04 February 2002 15:02, you wrote:
>
>>The Reconfigurable/Recontextualizable offer container managed rewriting, or
>>updating. It is not always practical to have the container manage all
>>aspects of the configuration in the container--although it is completely
>>practical and correct to do that for composable.
>>
>>The Component cannot rewrite or change the Context or the ComponentManager
>>in any way, nor should it. It does require some limited ability to rewrite
>>the configuration information as one configuration does not fit all
>>implementations of an interface.
>>
>
> Well, perhaps there are exceptions. Ever heard/read about the "HMVC"
> pattern? http://www.javaworld.com/javaworld/jw-07-2000/jw-0721-hmvc_p.html
> Following this pattern, any of Jakarta's Components (in HVMC "Controller")
> would be a ComponentManager at the same time and any Component would have
> access to its parent (container) using "getParentController()".
I am not in favor of any child able to abtain a reference to the parent
directly. This violates IOC, and can provide some serious security problems
in systems that dynamically load and use Components. There is good reason
why all our systems force one way interaction. Whatever we do, we have to
maintain the contract that the Container manages the COmponent in a manner
that the Component cannot control how it is managed.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Pairs of concerns + HMVC Components?
Posted by Christian Heller <ch...@tuxtax.de>.
On Monday 04 February 2002 15:02, you wrote:
> Stephen McConnell wrote:
> > Take a look at:
> >
> > org.apache.framework.configuration.Configurable
> > org.apache.framework.configuration.ReConfigurable
> >
> > org.apache.framework.configuration.Contextualizable
> > org.apache.framework.configuration.Recontextualizable
>
> Steve, he was referring about the ability to rewrite the configuration file
> based on run time systems. I.e. the ability for a Component to manage how
> to rewrite the old configuration format to the new configuration format, or
> the ability to add new entries. For instance, Axis has a run time that can
> install new web services, and it needs to be able to write the new
> configuration information to a file.
Thanks for explaining that, Berin! I guess, it was my bad English...
> The Reconfigurable/Recontextualizable offer container managed rewriting, or
> updating. It is not always practical to have the container manage all
> aspects of the configuration in the container--although it is completely
> practical and correct to do that for composable.
>
> The Component cannot rewrite or change the Context or the ComponentManager
> in any way, nor should it. It does require some limited ability to rewrite
> the configuration information as one configuration does not fit all
> implementations of an interface.
Well, perhaps there are exceptions. Ever heard/read about the "HMVC"
pattern? http://www.javaworld.com/javaworld/jw-07-2000/jw-0721-hmvc_p.html
Following this pattern, any of Jakarta's Components (in HVMC "Controller")
would be a ComponentManager at the same time and any Component would have
access to its parent (container) using "getParentController()".
In short, everything is a tree in the end, isn't it? Even the operating
system has a root process from which everything starts. In the same way,
every Component can be a root component (which is already considered in
Avalon) and at the same time a container for other components (which would
be new since the Container or ComponentManager would have to be eliminated).
There is a very fine project which has implemented HMVC: Scope
http://sourceforge.net/projects/scope
Our project is based on that architecture.
Best regards,
Christian
--
http://www.resmedicinae.org
- Information in Medicine -
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Pairs of concerns
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
> Take a look at:
>
> org.apache.framework.configuration.Configurable
> org.apache.framework.configuration.ReConfigurable
>
> org.apache.framework.configuration.Contextualizable
> org.apache.framework.configuration.Recontextualizable
>
Steve, he was referring about the ability to rewrite the configuration file based
on run time systems. I.e. the ability for a Component to manage how to rewrite
the old configuration format to the new configuration format, or the ability to
add new entries. For instance, Axis has a run time that can install new web services,
and it needs to be able to write the new configuration information to a file.
The Reconfigurable/Recontextualizable offer container managed rewriting, or updating.
It is not always practical to have the container manage all aspects of the configuration
in the container--although it is completely practical and correct to do that for
composable.
The Component cannot rewrite or change the Context or the ComponentManager in any
way, nor should it. It does require some limited ability to rewrite the configuration
information as one configuration does not fit all implementations of an interface.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Pairs of concerns
Posted by Stephen McConnell <mc...@apache.org>.
Take a look at:
org.apache.framework.configuration.Configurable
org.apache.framework.configuration.ReConfigurable
org.apache.framework.configuration.Contextualizable
org.apache.framework.configuration.Recontextualizable
Cheers, Steve.
> -----Original Message-----
> From: Christian Heller [mailto:christian.heller@tuxtax.de]
> Sent: Sunday, 03 February, 2002 16:16
> To: avalon-dev@jakarta.apache.org
> Cc: resmedicinae-developers@lists.sourceforge.net
> Subject: Pairs of concerns
>
>
> Hi,
>
> I miss the counterparts of some methods in your Framework. For example,
> the Configurable should get not only a method "configure" but
> also a method
> "deconfigure" (or "unconfigure", I'm not so good in English). The same for
> method "compose" which should get a counterpart "decompose" etc.
> In general,
> I guess that all methods should appear in pairs.
>
> Explanation:
> When I execute/run an application ("component"), it gets
> configured. In its
> lifetime, the user may change several settings. When the component is shut
> down, the new settings will have to be stored into the
> configuration file or
> database or whatever. So, a method "deconfigure" could be useful.
>
> Regards,
> Christian
>
> --
> http://www.resmedicinae.org
> - Information in Medicine -
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>