right. the issue/goal with 'last-modified' is that calculating
'last-modified' will be cheaper than rebuilding the whole output. This
has to be application specific, it can not do this without application
specific intervention.
Most components have no concept of what data they are rendering or
doesn't know how to calculate last-modified efficiently, so they have to
return "null" or "now", the cycle would continue down the tree.
Eventually this cycle will ask one of the application components which
does know about the data that it is rendering and knows how to calculate
the 'last-modified' in a more efficient manner than rendering the whole
output. That then components returns the appropriate last-modified
value. Then cycle would then return the latest value, and use that for
the whole page.
The last-modified strategy requires application specific knowledge about
what the page/component is rendering and how to calculate last-modified
in an efficient manner, else there is no way to calculate it, then you
might as well disable calculation of last-modified all together.
Brian K. Wallace wrote:
The problem with your description of a 'last-modified' process of asking
each component what it's last-modified time was is:
1. With caching enabled, the question is irrelevant.
2. With caching disabled, the question could be irrelevant - it
depends on what the component does. If the component retrieves the
latest entries from a database, the component may not have changed - but
the entries may have. This would require the component to build itself
in order to know if it had truly changed. Past that, you aren't saving much.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]