On Thu, 2002-06-13 at 12:53, Marcus Crafter wrote: > Hi All, hi =)
> Last week I started a thread about easing the implementation > of custom markers within Avalon. for starters, I think the term "markers" is a bit of...a marker is more or less an empty interface in avalonspeak. I'd call these custom lifecycle interfaces. > o Validation that the standard avalon interfaces are not tampered > with. ie. reordered/removed/etc. I think you should make sure these customisations separate of the rest. I also think it is not a good idea to modify the avalon containers to sustain more lifecycle stages. Rather, I'd suggest this need is solved by creating a tool to easy writing a custom container (hey, this belongs in containerkit!). Note that we had a lot of this stuff at one point (for phoenix), using a generic pipeline processor. We removed it because it made everything more complicated. > o Performance penalty incurred due to increased use of > dynamics/reflection. This new code *does* decrease performance > compared to the previous 'instanceof LogEnabled, instanceof > Contextualizable' way. There are probably ways to improve > performance though that need to be investigated. more use of static, abstraction away from xml format (so you can just create a configuration programmatically), probably loads. I think the key is to keep the instanceof for the avalon framework bits, then do whatever you want for the custom interfaces (you might not need performance there). > Ok, hope the explanation wasn't too terse. nah. Didn't need to look at any code =) > Would be great to hear what you all think. summarising: - not marker, but lifecycle stage - not container modification, but container toolkit to ease creation of custom container - keep lifecycle processing for avalon framework lifecycle stages separate, and as simple as it is now - will definately be useful cheers, - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
