The "separation of concern" -as is understood by MVC Web frameworks- does not separate concerns really. A separation of concern forced by technological problems rather than being separated by components of the problem domain is like saying that I live better as an slave because I have no need to be concerned by how good or bad the master behave. Caching is an example of this contradiction.
The MVC model forces his own separation of concern and it is inherently non composable. It does not allow to create self contained elements -with M V and C components inside- that can be composed to create applications. That means that it can not separate the concerns in terms of application functionalities: login, payment, content management, lazy loading, auto-completion widgets etc. As well as other functionalities specific of the individual application. The separation is dictated from below. That is because the technologies involved: event-driven graphical presentation, transactional data management and business logic are not yet fully integrated. See: Towards a deeper integration: A Web language
Concerning caching, A HTTP guru, probably in other department does not know for how long your particular data is valid . Neither you know if the HTTP guru will cache your fresh data in order to avoid loading the server, so you will add a random string to your data to avoid caching. In any case, there is a opportunity lost for optimizing the load of the server without impairing the interaction.
Now the new composable caching policies of MFlow permits the use of aggressive caching policies even for highly dynamic pages, since expressing cache directives is in the hands of the programmer of each particular widget.
What if you, the programmer of a widget can say to the page: "this widget present data that can be cached for 200 seconds, no matter if it is part of a page or if its data is sent trough Ajax". Or: "the user has logged-in so this page must be private, no matter the policies of the rest of the widgets".
What if the page can get all the cache policies of all the widgets and insert the most restrictive ones in the HTTP header?
Then we would have a true separation of concern without impairing synergies.
If the widget is refreshed using ajax, only the individual cache policy of the widget is taken into account. For example: I´m logged here as editor, so the login widget detect this condition and mark the page as private. But If I click an autorefreshed widget which is not marked as private and have a maxAge directive, the menu options on the left, for example, then the menus can be cached within network proxies and CDNs, so other users can make use of these cached resources without compromising my privacy.
Going this way, more synergies appear in unsuspected ways; What is the killer application of the JavasCript frameworks? To present data sets without repeated accesses to the server using the new HTML5 cache. Now this can be done by caching AJAX responses in the good old HTTP cache, and make it work in any browser without explicit JavaScript programming.
Because blogger is almost impossible to tame for me. I leave a link to the full article about composable caching in the MFlow demo site:
See also: Navigating an (infinite) dataset
