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.
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 if I say 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,
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.
Take for example dField:
Present a widget via AJAX if it is within a
Take for example this code from this page
<span id="p5iter"><a href="/noscript/templates/runtimetemplates/listnames/itertrue"><b>next</b></a> </span>
<span id="p6iter"><a href="/noscript/templates/runtimetemplates/listnames/iterfalse"><b>prev</b></a></span></div>