hi werner, it's the other way round - a jsf impl is able to do way more in a portable way (as soon as it is in the spec) than codi. what we should prototype (imo): - window-id - request token
regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/5/11 Werner Punz <werner.p...@gmail.com> > Hi why not introduce a url param as view window/tag token and > then basically hook the map history in the session onto this token if > given. > We could use codi window id for that token. If present we can handle > multiple maps per session if not then we run within the old scheme. > Outside of codi you simply have to duplicate the window param id one way or > the other. > > Unless we have a different way to identify different maps depending on > their window. > The viewstate history param then would map to number of views per window > and if no window id is given we basically run in the old scheme just with > one indirection more in accessing the viewroot from the session point of > view. > I dont think any of those changes would break the spec. > > > Werner > > > Am 11.05.11 04:49, schrieb Leonardo Uribe: > > Hi >> >> There is an old, known problem related to server side state saving, >> that becomes more evident in JSF 2.0 and its ajax support. >> >> For more information about it, you can see: >> >> https://issues.apache.org/jira/browse/MYFACES-3117 >> Current server state saving implementation prevents multi-window usage >> https://issues.apache.org/jira/browse/MYFACES-1791 >> state management and multiple frames >> >> The objective of this mail is get some information from MyFaces >> community, given the difficulty involved in solve this problem. >> >> In few words: "... There is a problem in JSF when more than one window >> are opened in an application. There are only a maximum number of >> NUMBER_OF_VIEWS_IN_SESSION view states saved at one moment (when >> server side state saving is enabled). If 2 windows are opened and you >> navigate on one of them for NUMBER_OF_VIEWS_IN_SESSION times, you will >> lose the other window's state. ..." >> >> MyFaces algorithm for cache sessions is just a Map with a limited size >> that just save every view and remove the least recently used one. >> >> The limit is configured using this web config param: >> >> org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION >> >> That defines the number of views per session allowable by an specific >> user. >> >> To solve this issue, we must consider two valid use cases: >> >> 1. Back Button: The user press browser's back button and then do a >> submit. In practice, there are some cases where press browser's back >> button is valid, but others where a back button should not be allowed. >> 2. Double Submit: The user press twice the submit button. >> >> Many efforts has been done in this area, for example see the this post >> from Mario Ivankovits: >> >> >> http://myfaces.apache.org/orchestra/myfaces-orchestra-core/multiwindow.html >> >> and in the latest times, there is some code interesting code in MyFaces >> Codi. >> >> A real solution for this one should be handled at level spec, but that >> does not means we can't do anything from myfaces side. >> >> I'm thinking on make our caching strategy more smarter when it decides >> which view should be removed from the map, creating a new param that >> limits the number of views that can be stored from sequential POST >> requests. This will limit the amount of browser back button clicks >> without get an expired exception, but on the other side it will >> preserve the views available for other windows doing other POST >> requests. Note this will not work on applications that uses >> POST-Redirect-GET pattern. >> >> Suggestions are welcome. >> >> Leonardo Uribe >> >> > >
