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.
another problem is that everything now needs to be a post since the
data is stored in a hidden form field - that really sucks.
agree, but it would only be required when you have turned it on.
default would be off.
i dont think url will be able to hold as much data as a decent sized
page would produce.
agree. this would only work only for special cases.
-Igor
On 1/6/06, *Jonathan Locke* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
how hard would this really be? we simply store the IPageMap entry
in a
serialized hidden form field and put it back in the pagemap on request
handling. am i missing something?
Jonathan Locke wrote:
>
> so we do have stateless pages and we do have IPageMapEntry.
> two things:
>
> 1. what does the code look like to encode/decode params for a
> stateless page into url?
>
> 2. now that we have IPageMapEntry, it could make more sense to
allow
> page state serialization! rather than serializing the whole
component
> tree, you can tune the state sent back to the browser to just the
> state needed to reconstruct the tree (The IPageMapEntry object...
> which would only be the Page in the worst case where the user
does not
> care about bandwidth). seems like this combination of techniques
> could be a silver bullet for many who want stateless
pages. thoughts?
>
>
>
>
> -------------------------------------------------------
> 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
<http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click>
> _______________________________________________
> Wicket-develop mailing list
> [email protected]
<mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
-------------------------------------------------------
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
<http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click>
_______________________________________________
Wicket-develop mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
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
