Thanks for taking a look at this with me, comments inline:
Unico Hommes wrote:
I've checked out your event-cache code just now and like to make some comments.
One thing I found was that the EventRegistry.init() method breaks IoC in Avalon. I think it's better to have initialization be done by the Avalon container as part of lifecycle handling. This way Avalon can control when the component gets initialized. Since EventRegistry has a thread-safe lifestyle the same instance is available to other components as well. A property that tells whether or not persistent state was successfully regained would allow this.
I agree, and at various stages on my HDD it was that way. IIRC the issue I never solved cleanly was the fact that it needed to tell the Cache(Store) if there was a problem retrieving persistent state. At the time though I was not as confident in the lifecycle contract regarding dealing with other components in initialize(). But I now think IoC can be done more cleanly there pretty easily.
The other thing I was wondering about is why not use Store component in DefaultEventRegistryImpl so that it won't have to handle persistence itself?
I thought of that, but thought there could potentially be some circular issues there that I didn't have brain cycles to think through carefully. Actually, it could be the opposite: it may get rid of some of the issues with failing to retrieve persistent state, since it would either all be there together or not.
I have been thinking about an easy way to add all this functionality to the pipeline and figure that a nice way to do it is to have a sort of EventCacheGenerator that wraps any sitemap defined generator, delegating al the real generating to the wrapped generator but taking care of the handing out of Validity objects based on parameters it gets from the sitemap:
<map:match pattern="blah"> <map:generate src="event-cache"> <map:parameter name="delegate" value="file" /> <map:parameter name="event-type" value="name-value" /> <map:parameter name="event-name" value="db-table" /> <map:parameter name="event-value" value="customers" /> </map:generate> <map:serialize /> </map:match>
This way we get event-cacheable sitemap components without having to add that functionality to each individual sitemap component.
That's an excellent idea. You can see from the sample extended file generator in the block (which serves no purpose ATM) that I was thinking it would have to get handled by individually extending each Generator. Delegation would be much better.
This is actually based on a use case that came up yesterday from one of
our site developers. He uses cinclude transformer for content
aggregation. Some parts are generated from a backend for which we have
an event-cache equivalent system in place. The cinclude transformer has
only a timeout sort of caching mechanism as you may know, but our
client's case requires real-time updates so we can't use that. Instead
he needs the content-aggregating pipeline to be invalidated at certain
backend events as well. In this case probably a declaratively more sound
approach would be to also have a Transformer wrapper for event-cache.
If you want I could code these up and send them to you? What do you think?
That'd be great - except it'd be better to send a patch through Bugzilla so I'm not the only one who can act, and so it doesn't get lost. When my wife & kids get back this afternoon I may be out of commission for a few days!
Geoff
