Mario, you are not alone in hating the shared concept. ;-) This is exactly where the "myfaces-commons-xxx" library comes into play, I often mentioned before. What we need is a module, that 1) has a super stable API 2) is used (ie. shared) by the myfaces core(!) as well as other myfaces projects 3) may be used by the experienced JSF app developer who wants to write his own StateManager or ELResolver or some other pluggable/replaceable JSF thingy (ie. all the things you can replace via faces-config.xml)
Problem here again is the name of such a lib: "myfaces-commons-base"? "myfaces-commons-core"? "myfaces-commons-super"? "myfaces-commons-commons"? ;-) The name MUST reflect the fact that this jar is a very basic lib all other JSF stuff depends on. It is no place where we swiftly drop some nice and convenient utils stuff and the API is nothing to play around with. I think that if we find a good name and define some strict rules we could move most (or all?) stuff from myfaces-shared to this lib. And perhaps even get rid of shard in the long run! Of course, some well-known issues pop up immediately: which JSF-Spec - 1.1 and 1.2 or only 1.2? What about JSF 2.0? Thoughts? --Manfred On Tue, Apr 1, 2008 at 9:31 PM, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > > Just to reiterate: I hate shared! ;-) > > Seriously, it seems that Orchestra has to implement a StateManager which > holds the view state in the conversationContext instead of the session. > At the moment it seems that large portions of JspStateManagerImpl can be > reused, but requires to copy it over into Orchestra. > > With slight refactoring of JspStateManagerImpl it should be possible to > just replace the actual storing/loading stuff. > > Does this qualify to move JspStateManagerImpl into shared? Or should I > better copy the source over? > > Ciao, > Mario > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
