Howard Lewis Ship wrote:
I suspect that, going forward, full page renders will often be the
exception, rather than the rule. That is, you'll have a full page
render, then a series of partial renders. In many cases, the result
sent back to the client will not even be HTML markup, but will be an
(XML?) data stream interpreted by JavaScript running in the browser.
** client-side-inclde
Interesting. I have been waiting for the concept of Client-Side-Include
for a while, and maybe tapestry will be build totally around this
concept in the future. For now I just created tapestry components to do
so client-side-include, but then I had to create simple pages just to
render the desired html fragment.
** last-modified
I am not sure if I have mentioned it before, but please as you guys are
thinking about the framework please work in proper support for
last-modified checking! and expires setting! for any render/request.
This simple technique can easy multiply the number of users the system
can handle, for zero cost ( if you were already planning on rendering
everything anyhow ).
I have been dreaming of refactoring the rewind cycle operation to add a
last-modified cycle, that would walk through the tree and ask each
component it's last-modified time, and then aggregate that information
somehow to determine the page's last-modified time. Then determine
after that if we actually go through the final render step. This saves
resources all around ( cpu, memory, response time, bandwidth ).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
