Basically, what you are proposing is to create a hierarchy of ECMs/ECS rather than a single-level-deep structure, IIUC. The advantage of this is that using a tree instead of a map results in better maintainability in larger projects. Right?
The disadvantage is providing unneccessary functionality in simpler setups and degrading performance. The question is whether the majority of use cases will be so complex as to justify the tree approach. I'm guessing this is not the case. If this is true, I would say that the tree approach should be an alternative to the standard ECM/ECS. And to answer your question: > - What is the opinion regarding components-that-have-components > in Avalon? > Is this a no-no, with the exception of ComponentSelector? the idea always has been that components-that-have-components manage that relationship through a ComponentManager, and optionally, a ComponentSelector. This to promote Inversion of Control. You should only break IoC if you really need to. Do you? grz, - LSD > -----Oorspronkelijk bericht----- > Van: Leo Sutic [mailto:[EMAIL PROTECTED]] > Verzonden: zondag 3 maart 2002 22:52 > Aan: Avalon Developer's List > Onderwerp: [Proposal] ECM / ECS / AbstractContainer > > > All, > > there is a lot of code duplicated between the > ExcaliburComponentManager and > the > ExcaliburComponentSelector. Basically, they both implement > Contextualizable, > Composable (ECM only), RoleManageable and LogKitManageable. These > interfaces > are just implemented in order to pass on the context etc. to the > ComponentHandlers. > > The code for this is also very useful for any other > Component-that-has-subComponents. > > My example is this: > > I have a component that will use the strategy pattern. That is, it has a > method > that is something like this: > > public Action whatToDoNext (Context context); > > So, given something, it will return an action for the context. Now comes > the fun part: It solves this by having another component within itself > that it passes the context on to and recieves an Action in return. > > *That* component may in turn have sub-components. > > So, I end up with a decision tree where the nodes are components. > > For example, suppose we want to do A in the afternoon and B > otherwise, with > the exception that instead of B, we should do C on Sundays. > > Sunday +--------------- C > | > AM +-------- DayOfWeek ---------- B > | Otherw. > Root ---- TimeOfDay > | > PM +--------- A > > > Each node in the tree would be a component, that could possibly have > subcomponents. > > The configuration would look like this: > > <tree-root> > <rule class="TimeOfDay"> > <when start="0" end="12"> > <rule class="DayOfWeek"> > <when start="Monday" end="Saturday"> > <action class="B"/> > </when> > <when start="Sunday" end="Sunday"> > <action class="C"/> > </when> > </rule> > </when> > <when start="12" end="24"> > <action class="A"/> > </when> > </rule> > </tree-root> > > In Cocoon this is solved by looking up the matchers (equivalent to the > DayOfWeek and > TimeOfDay classes in the example) via a ComponentSelector, and passing a > pattern > to them. This is suboptimal when each component instance in the selector > is only used in one place and I would end up with the following > instances in > the Selector: > > <rule hint="root" class="TimeOfDay"> > <when start="0" end="12" then="day-of-week"/> > <when start="12" end="24" then="A"/> > </rule> > <rule hint="day-of-week" class="DayOfWeek"> > <when start="Monday" end="Saturday" then="B"/> > <when start="Sunday" end="Sunday" then="C"/> > </rule> > <rule hint="A" class="FireA"/> > <rule hint="B" class="FireB"/> > <rule hint="C" class="FireC"/> > > Of course, if we want to select between weekdays in another part of the > tree - say, do D instead of A on Saturdays, we get an additional: > > <rule hint="day-of-week-saturday" class="DayOfWeek"> > <when start="Sunday" end="Friday" then="A"/> > <when start="Saturday" end="Saturday" then="D"/> > </rule> > > (And don't forget to update the hint="root" rule to reference this new > rule!) > > And so on. As the tree gets flattened, maintainability is lost, > and I would > like > to solve this by allowing each component to have sub-components, > just like a > ComponentSelector can select among several sub-Selectors. > > This would also allow for powerful rule-based ComponentSelectors to do > N-dimensional > lookups, where the rules need not be coded into the ComponentSelector. > > THE PROPOSAL: > > Attached is an implementation of AbstractContainer and > ExcaliburComponentManager, > modified to inherit from AbstractContainer. > > The AbstractContainer class gathers all the references necessary to create > ComponentHandlers - it does nothing more. What happens with the handlers > is up to the subclass. > > I propose that this replace the current implementation of ECM, > that the ECS > is rewritten to derive from AbstractContainer, and that AbstractContainer > is make part of Excalibur. > > I am not calling a vote just yet. > > I am also looking for input regarding: > > - What is the opinion regarding components-that-have-components > in Avalon? > Is this a no-no, with the exception of ComponentSelector? > > /LS > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
