Hi Peter, answer inline as usual: > -----Original Message----- > From: Peter Donald [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 11, 2002 3:01 PM > > > On Sat, 12 Jan 2002 00:54, Paulo Gaspar wrote: > > > It may be clearer to use the term ServiceManager rather than > > > ComponentManager > > > because that has a easier to grok description of what a CM is > > > meant to do. > > > For sharing of generic resources that are not services but data > > > then Context > > > is probably the place for it. > > > > ...this makes it much less confusing. =:o) > > kool.
But not the Context bit! =;o) > > Ok, what I am proposing is for Avalon (Framework + Excalibur) 5 > to have a > > brand new ComponentManager which could provide the core > functionality for > > the ServiceManager (now called ComponentManager). > > > > So, Avalon would get BOTH a Service Manager and a Component > Manager. This > > would make the framework quite a bit more generic and I think > it would be > > of better use for projects like Ant-Myrmidon and Cocoon. > > What would be the difference between an Avalon4 Context and an Avalon5 > ComponentManager ? Let me answer you with a question: What is the difference between an Avalon 4 Context and an Avalon 4 ComponentManager? The only difference between and Avalon 4 ComponentManager and an Avalon 5 ComponentManager is the way you index components - i.e., the format of the lookup key. > > I mean, my "Sitemap" does a lot of the same that Cocoon's > Sitemap does and > > I just use my standard ComponentManager and Configurator > functionality for > > that. They have to do a lot more manually I think. > > I think Context is meant to do that. Essentially Avalon4's > Context serves 4 > "styles" of context. It actually has similarities to context as > defined in > linguistic theory ;) > > 1. World Context / Per-Application context: So this describes application > wide settings. An example may be the working directory of the application. > > 2. Person Context / Per-Component context: This contains context > information > specific to the component. An example may be the name of the component. > > 3. Conversation Context / Per-Session context: This contains context > information specific to the component. An example may be the IP > address of > person who you are talking to. > > 4. Speach Act Context / Per-Request context: This contains > information about > a specific request in component. Example may include the > parameter submitted > to a particular web form or whatever. > > When we implement this (1) and (2) are generally merged into one > interface. > For instance in pheonix we have a block context that among other > things has > two methods. One is getHomeDirectory() and that belongs to (1) while the > other is getName() which belongs to (2). > > (4) is usually passed into a service() style method as > parameters. So you may > have something like I use Contexts these ways too. > void doMagic( int param1, int param2, Context otherParamsInHere ); > > When (3) is needed in the system it is usually also passed into > the "service" > method or alternatively it is made available via the context > representing (4). > > My memory is sketchy but I believe C2 used an Environment object that was > basically the Per-Request parameters and Per-Session stuff. > Though I don't think it extended Context or anything like that. No, but I think it holds a Context. I am not sure. (I know mine does.) > hmm .. maybe I should should condense/clean this explanation and > place it in > the javadocs ... YOU SURE SHOULD! =:o) > -- > Cheers, > > Pete > > *------------------------------------------------* > | You can't wake a person who is pretending | > | to be asleep. -Navajo Proverb. | > *------------------------------------------------* LOL! Have fun, Paulo Gaspar -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
