Mario Ivankovits schrieb: > Hi! > >>>> Does this qualify to move JspStateManagerImpl into shared? Or should I >>>> better copy the source over? >>>> >>>> >>>> >> There are some jira issues and email threads that might be relevant: >> >> > Thanks for the links, for me it seems there is need for this for other > "experiments" too. So, I'd move this class to shared and refactor it a > little bit so that it can be easier subclassed and allow only the bits > changed one is interested in. > > However, I don't want to go to solve the window-problem for MyFaces at > all, but just for Orchestra which seems to be easy due to the already > existent conversationContext parameter. >
Ah. The point you were making is that things other than myfaces-core might want a basic JspStateManagerImpl implementation for them to subclass. And that is what "shared" is for. Whether JspStateManagerImpl could be refactored to support alternative strategies is a different issue. Sorry about the red herring. Orchestra having its own JspStateManagerImpl sounds "interesting" though. Enabling this on Sun Mojarra for example will quite radically change the way that a JSF app on Mojarra performs. That's not really Orchestra's role. What is *really* needed is for the StateManager spec to have some mechanism to externalise the state, then have Orchestra override just that. Is it not possible to apply the "decorator" pattern to whatever StateManager implementation the current JSF implementation provides? Regards, Simon
