The application has to ensure that the cache is kept up to date anytime. This means that after a response is returned all new values already have to be pushed, or removed from the cache. This is done with the help of the Scales API that enables to push whole resources like HTML files, XML files and raw data like images, or partial like HTML divs that can be selected using CSS or XML nodes that are selected using XPath. Usually the place for these API calls are the controller of the application, as the controller joins the model and the parsed resource.
The push API allows to create or update whole resources like this:
The update API allows to specify multiple URLs that need to be updated before the current request returns. For example the create action for a post
usually pushes the actual post to the cache, but the post also needs to appear in the index of all
/posts. In this case a simple update call to
/posts is executed and pushes the latest posts to the cache before the create request returns so everything is set and ready.
The modify API allows to change only a small subset of a resource without re-rendering all of it. This, for example is very handy when data needs to be appended, but the cost for recalculating the old data is just to high.
The destroy API simply removes resources from the cache. This is usually done after the deletion of the resource.
The partial API implements the idea of partials on a cache level. This allows to mix and combine different resources by calling
in another view. Partials can be pushed using the push API. Note that there is no leading "/" to the key. This prevents it from being published and accessible by URL.
You can nest as many partials inside each other as you like. To resolving however then takes longer, of course.
Partials are especially useful for navigation bars and menus. If a menu contains a list of posts, all pages that show the menu would need to be updated if a new post is created. With partials only the partial can be updated and you're done.