Howdy ho,
At 06:01 PM 6/13/2002 +0200, you wrote:
> Or, are you saying we should make the startup phase immutable and
> not extendable, but allow for access level extensions ?
+1
I spent ages trying to get this work. We went through several iterations of
Phoenix trying to enable this but it was an absolute PITA and massive
headache to maintain. The way I would recomend you implement container
specific behaviour (like Instrumentation etc) is via a Container-specific
context.
ie Phoenix has a BlockContext via which it exports extra information to
blocks (if they want it) and also will support extra functionality in the
future.
Note that I haven't read your proposal yet but my guess would be something
like the following would work
interface CocoonContext extend Context
{
InstrumentPoint getPoint(String name);
CocoonSession getSession();
File getWorkDirectory();
///insert whatever actual parameters you need
}
Then your instrumentable component just does something like
abstract class AbstractCocoonInstrumentable
implements Intrumentable, COntextualizable
void context( Context c )
{
CocoonContext cc = (CocoonContext)c;
setPoints( cc.getPoints() ); //Or however instrumnentable works
}
I have used the same pattern over and over again and it works well. What do
you think ? Does it work for you?
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
