Johan Compagner wrote:
Should a developer override Session.newPageState(Page) or the page.newPageState()?
depends on whether you want to provide a new way of compressing /all/ pages or just one.
Because in the docs the Session.newPageState are saying that it is a default slow implementation
"The default, inefficient implementation is to simply wrap the entire Page object"
I think that comment should be in page.newPageState() i believe because there the wrap entire page is done
not in Session.newPageState().
correct. the comments have fallen behind the changes a little.
And i think developers will use page.newPageState() for the better implementations because a page knows exactly what he can or can't do for itself (i think)
yeah, Session.newPageState() is really not something most developers would ever use.
but someone would use the other method to implement, say, that xml serialization thing johan was talking about...
We should write a nice example for this what would be a very good implementation, because currently i think most developers don't know what to do there.
yeah, chris was talking about doing this and testing it on his little cluster of three.
i have no idea, in fact, if any of this actually works... it just /ought/ to... ;-)
jon
johan
Jonathan Locke wrote:
okay, so i think the last of the changes we'll need for clustering are in now and it's really quite flexible. both chris and i are quite happy with it. so let's see what we messed up now... ;-)
the checkin messages give some details, but what was done from an end-user perspective was this:
1. Pages are replicated across the cluster individually now and only when a Page is added or changed
a. changed pages are now signaled by a call to Session.pageChanged(Page)
b. calls to this method will be added to Page as we implement undo() support
2. other state is contained in an internal implementation class Session.State now
a. this state information is only replicated when it is actually dirty
b. if no Page is changed and no session State is changed, nothing will be replicated on a request
3. the new PageState class and Session.newPageState(Page) method allow a programmer to implement any scheme whatsoever for transporting Pages from one node on a cluster to another
a. when a page is changed, Session.pageChanged(Page) calls newPageState(Page) allowing your (Web)Session subclass to specialize the way PageState records are created for a given Page
b. these PageState records are used to "freeze dry" and "reconstitute" Pages stored as session attributes
c. notice that the fact that you can override Session.pageChanged(Page) means you can create any kind of serialization or compression algorithm you might care to
d. the default implementation of Session.newPageState(Page) simply calls Page.newPageState()
e. this means that any Page subclass (for example your own WebPage subclass) can create a PageState "freeze drying wrapper" for efficient replication of the Page across the cluster.
f. there are no limitations on what you do in your PageState class for a given Page so long as you can return a Page when asked for it
did i miss anything chris?
jon
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
