it definitely can get harder. but it depends on the page. you can
imagine a pretty complex page too where the whole page can be
reconstructed in the correct state from just the page constructor
arguments... you just save the arguments and you can rebuild from that.
i personally would probably not use this feature even on a high volume
site, perhaps unless it truly had to be clustered. but it seems not too
hard to provide and it gives users options and critics (who may or may
not be well informed) less to find lacking.
Igor Vaynberg wrote:
On 1/6/06, *Jonathan Locke* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Igor Vaynberg wrote:
> possibly the fact that pages with large component hierarchies ( ie
> pages with repeaters ) will be huge when serialized and base64ed. so
> you end up with client side pages that are huge - this is pretty
much
> exactly what jsf does.
yep. but as i was saying... if you care, you can get rid of the
majority of that (all the component state and overhead that doesn't
really matter) by implementing IPageMapEntry. you're trading time
for
space.
i dont know if this is all that possible without breaking component
encapsulation. components might have internal state that the user
cannot get to so it cannot be made part of ipagemapentry.
i think this is doable for simple pages, but for more complex ones i
dont know.
-Igor
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
