hi leo, @window-id:
we have a window(-id) concept e.g. in trinidad, icefaces, cdi (at least a conversation-id which should be specific to a window), codi,... . so we again have incompatibilities (esp. in case of dialogs,...) which can't be solved by just wrapping something. -> adding the concept to the spec. is a good idea in any case. >furthermore, a spi would allow to implement a myfaces-core2 specific add-on for libs like codi. -> still +1 for prototyping it + a spi for using it for e.g. a codi/myfaces-core2 add-on. 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 Leonardo Uribe <lu4...@gmail.com> > Hi > > Working on this stuff I have found a problem with our current > ResponseStateManager implementation. The spec javadoc says this: > > "... ResponseStateManager is the helper class to StateManager that > knows the specific rendering technology being used to generate the > response. It is a singleton abstract class, vended by the RenderKit. > This class knows the mechanics of saving state, whether it be in > hidden fields, session, or some combination of the two. ..." > > For this particular problem, that means if we need a windowId using > url/hidden fields/cookies or whatever, the standard solution could > include a wrapper or alternative implementation of > ResponseStateManager, setup using a RenderKitWrapper (since JSF 2.0). > If that so, there is no need for any SPI interface, because the spec > has already seen that. > > In practice, frameworks like trinidad for example just override > ViewHandler/StateManager/ResponseStateManager, so we have never seen > anything wrong per years in our implementation ... until now that we > want to try a wrapper for this class. > > Note on the spec javadoc this subtle phrase: "... This class knows the > mechanics of saving state ..." What that suppose to mean? It means > that the responsibilities of ResponseStateManager are: > > 1. Deal with RenderKit specific state saving mechanism (use hidden > fields, javascript, ....). (Ok, that's pretty obvious but the next one > is not.) > > 2. Deal with client/server side state saving details, including > storing/retrieving/caching operations. > > I deducted the second one doing the cleanup of the code. To isolate > the storing/retrieving/caching code I created a class called > StateCache, but after a closer examination, I saw that each time > StateCache is called, ResponseStateManager was called too to consume > or provide params to this class. So it has more sense to put that code > where it really belongs, inside our ResponseStateManager > implementation. Just for curiosity I checked if Mojarra, is doing this > and it is, so there is no doubt. > > So, what does StateManager really do? this class deals with > save/restore the component tree and delegates the remaining stuff to > ResponseStateManager. The same is for > javax.faces.view.StateManagementStrategy, but in this case, this class > is more coupled with the VDL implementation. > > Now, for the case we are discussing, any solution for this one should > provide its own implementation/wrapper for ResponseStateManager and > some other classes (maybe override ExternalContext and ViewHandler to > append windowId query param or anything you can imagine). It is > obvious that frameworks overriding the default ResponseStateManager > will require a custom variant, but I think is the way to go. > > From the spec point of view, I think we can create additional > interfaces to deal with operations like caching and state encryption, > but for now there are implementation details for each > ResponseStateManager implementation. > > So, the plan for now is fix MyFaces ResponseStateManager > implementation (I'll commit it soon) and add the param to limit the > views stored with sucessive postbacks as a "partial workaround". To > solve the window problem it is possible we need a "combined solution". > > Comments and suggestions are welcome. > > Leonardo > > 2011/5/11 Gerhard Petracek <gerhard.petra...@gmail.com>: > > 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 > >>> > >> > >> > > > > >
