I just re-visited the (old) Portlet API proposal, to see if it handled our needs for state as described in the state manager proposal.
The minimized, maximized state of a portlet was called the "PortletWindow" information in the old proposal. This is *not* the information we are considering for portlet state. I consider this more the portal page's (or pane's) state, and the old proposal collected this in a separate object given to the portlet with the request. Examples of the sort of information that the StateManager handles for portlet instance state are in the proposal; things like where a user is in a wizard, which folder a user is viewing in a browser, etc. The old proposal had a concept called "PortletSession", which at first glance might look like it covers our state. It does not, though. The scope of the PortletSession (as best I can derive from the old proposal documents) is much wider than the scope we need - there would be one PortletSession for not only many different portlet instances, but for many different portlets as well. While useful for other purposes, it does not help with portlet instance state. Scope is the key to the StateManager proposal; the portlet instance state is good for a single placement of a portlet on a single portal page for a single user session. The way that the old proposal delivers all the different sorts of information to the portlet for processing is by having the portal engine collect it all and place it in the portlet request (our RunData). This may be a promising thing for us to do. We can add a PortletInstanceState object to the rundata (it would have get/set attributes, and be scoped as per the StateManager proposal). We could also add a R/O object that has configuration attributes (from the registry) and another R/W one that has the customization attributes (from the PSMLDocument. Let the portal engine pull this all together for the Portlet. Clean up our Portlet API. This may be a solution to a problem we are currently having with Jetspeed, but is a much bigger change than proposed in the StateManager proposal. Although bigger, the change itself would be localized to the rundata service and perhaps the PSMLDocument and Registry classes. The current Portlet API way that this information is accessed can become covers to rundata calls, and become deprecated. I am willing do this now, though, if we want it. - Glenn -------------------------------------------- Glenn R. Golden, Systems Research Programmer University of Michigan School of Information [EMAIL PROTECTED] 734-615-1419 -------------------------------------------- > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 11, 2002 11:14 AM > To: [EMAIL PROTECTED] > Subject: RE: State Manager Proposal > > > Glenn, > I have a question I hope you can help clear up for me. It > appears that the StateManager is quite similar to a possible > PortletSession. How would this StateManager differ from a > PortletSession? > > Wouldn't the state of a Porltet be something like its > condition, like minimized, maximized, etc? The proposal > seems to allow for a lot of data pertaining to the Portlet > outside of its State to be stored. > > What if each Portlet consisted of an independent Session for > each Portlet Instance and User. This would allow for any > transient information to be stored per Portlet Instance per > User. A wrapper on the session object to encode all > attributes with name space information could achieve this > goal. To encode with Portlet Instance - > PortletNamespaceMapper.encode(portletInsanceId(or peid), > attributeName) - any ids you want to use for encoding could > be added in addition to the portlet instance id. > > We are currently utilizing the PortletSession (from > portlet_api branch) with the current cvs version of Jetspeed > to achieve much of what you are proposing. I believe the > name of PortletSession would be less confusing than "State" > and that the PortletSession could be extended to meet the > additional needs in the proposal. > > Maybe I am completely off on what you are proposing as a > "State" of a Portlet. If so please explain. > > thanks, > Marcus > > -----Original Message----- > From: Glenn Golden [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 11, 2002 6:28 AM > To: Jetspeed-Dev ([EMAIL PROTECTED]) > Subject: State Manager Proposal > > > I have submitted a proposal for a State Manager capability > for Jetspeed. This can be found in: > > proposals\StateManager.txt > > For your convinence, a copy is attached. > > I look forward to your comments. > > - Glenn > > -------------------------------------------- > Glenn R. Golden, Systems Research Programmer > University of Michigan School of Information > [EMAIL PROTECTED] 734-615-1419 > http://www-personal.si.umich.edu/~ggolden/ > -------------------------------------------- > > > > -- > To unsubscribe, e-mail: > <mailto:jetspeed-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
