So I had a whisky inspired coding spree last night, and created a proof of concept package for a Umbraco Cache Dependency so that you can throw items into the .Net cache and apply a dependency on an umbraco node.
In the Proof of concept you can do this:
But future versions may look like this:
new UmbracoDependency(new ContentDependency(1234,1235), new DocumentTypeDependency("docTypeAlias"), new MediaDependency(124))
So you can apply dependencies to more that one type/flexibility.
Question time for the APIers Is it best that I have a "Proxy" for the events, which ties into the umbraco events and then locates the dependencies to remove (have the dependencies register with my proxy class on initialization and then remove themselves when the dependency is being removed), or is it best to directly tie into the umbraco events for each depencency and to remove the event from umbraco.
TL;DR: Best to have lots of umbraco event handlers or have a single event handler?
Option 1 is to have each dependency class register with a "proxy" class that would subscribe to the appropriate Umbraco events, and removes the dependencies.
Option 2 is to have each dependency class subscribe to the appropriate Umbraco events so it knows when to remove itself.
I guess 2 is simpler to code? But can create a big amount of handlers. Whereas 1 has only one handler... but needs to keep track of what to do when it runs. No idea really, keep it simple to begin with and benchmark to see what happens, I guess.
Side question: what would remove a ContentDependency: the content being published / removed / moved? What-if a parent of that content is published / removed / moved?
I'd probably have an option to enable parents, childre, etc as if it defaulted a parents everytime the homepage was changed, then the entire cache would be nuked.
Feedback req: Umbraco dependency provider
So I had a whisky inspired coding spree last night, and created a proof of concept package for a Umbraco Cache Dependency so that you can throw items into the .Net cache and apply a dependency on an umbraco node.
In the Proof of concept you can do this:
But future versions may look like this:
new UmbracoDependency( new ContentDependency(1234,1235), new DocumentTypeDependency("docTypeAlias"), new MediaDependency(124))
So you can apply dependencies to more that one type/flexibility.
Question time for the APIers Is it best that I have a "Proxy" for the events, which ties into the umbraco events and then locates the dependencies to remove (have the dependencies register with my proxy class on initialization and then remove themselves when the dependency is being removed), or is it best to directly tie into the umbraco events for each depencency and to remove the event from umbraco.
TL;DR: Best to have lots of umbraco event handlers or have a single event handler?
Cheers
Stephen
Just to make sure I understand:
Option 1 is to have each dependency class register with a "proxy" class that would subscribe to the appropriate Umbraco events, and removes the dependencies.
Option 2 is to have each dependency class subscribe to the appropriate Umbraco events so it knows when to remove itself.
I guess 2 is simpler to code? But can create a big amount of handlers. Whereas 1 has only one handler... but needs to keep track of what to do when it runs. No idea really, keep it simple to begin with and benchmark to see what happens, I guess.
Side question: what would remove a ContentDependency: the content being published / removed / moved? What-if a parent of that content is published / removed / moved?
Yup, thats exactly right,
Thanks for the input!
I'd probably have an option to enable parents, childre, etc as if it defaulted a parents everytime the homepage was changed, then the entire cache would be nuked.
is working on a reply...