RE: [Avalon4:PROPOSAL] Context Consensus
"Leo Sutic" <[email protected]>
| Newsgroups | gmane.comp.jakarta.avalon.apps.devel |
|---|---|
| Message-ID | <000501c2a11e$1cb2b5c0$0801a8c0__12042.2871703797$1039615299@Lagrange> |
> From: Leo Simons [mailto:[email protected]] > > my previous replies I forgot to send apparently, so here it goes... > > On Wed, 2002-12-11 at 00:23, Leo Sutic wrote: > > There is currently *not* consensus that a component should be able to > > specify any interface that it should be able to cast the context to. > > That is, for every class/interface T, > > > > public void contextualize (Context context) { > > T myContext = (T) context; > > } > > > > the component should be able to declare that it expects to cast the > > context > > to a T. (For a less abstract example, replace T with BlockContext.) > > note: the main reason I don't like this is because it means > the container impl must do proxying, which is heavyweight. Note that the proposal does *not* say that the container must be able to *satisfy* any request. It merely acknowledges that a component may *ask* for a context class T. You are free to disallow any components asking for a class in your container, if you think that the implementation of it would be too heavyweight. The same goes for the no-active-operations-in-context. The proposal says that the component may *ask* for such operations, but it also states that there are no *required* operations that all containers must support, meaning that your container can completely disallow any component requesting such an operation. The reason both these things are in the proposal is because it is impossible to capture the Phoenix usage pattern without them - i.e. you can't describe the requirements of a Phoenix block. Disallowing active operations at a Framework level would effectively put Phoenix into non-compliance with Framework, that's why a component must be able to *ask* for them, but a container must not have to supply them. Still a problem? > > ISSUES THAT HAVEN'T BEEN BROUGHT UP - INPUT SOUGHT > > > > 1. A list of canonical keys and their meaning can be found at: > > > > http://jakarta.apache.org/avalon/excalibur/info/context.html > > > > Should these be made Framework-wide canonical keys? > > yes. Noted. (With motivation.) > > 2. Should the context entries include an "isOptional" attribute: > > > > <entry intent="avalon:work" type="java.io.File" > > is-optional="true"/> > > > > ? > > I think this is a nice experimental feature that need not be > supported in avalon framework 4 till we figure out if it is > truly needed and in widespread use. There's other is-<blaat> > things one could think of. I suggest keeping it out of the proposal. Noted. (With motivation.) /LS