Hello B.J.,

Portlet preferences can be stored even in render phase if you can use 
Jetspeed-2 API component, 
o.a.j.components.portletpreferences.PortletPreferencesProvider, in your portlet 
application.
Of course, this approach with Jetspeed-2 specific API could be one you want to 
avoid as possible.
However, if you leverage a portlet filter for this custom stuffs, then you 
could keep the others as pure portlets.
I mean the followings:
- Just use portlet preferences in the portlet.
- Add a portlet filter which reads and modify portlet preferences with 
Jetspeeed-2 specific API components if necessary.
  So, the portlet filter can do pre-processing on each render request.

In the dedicated filter, you could use the following techniques:
- PortletPreferencesProvider can be accessed in either portlet or filter via 
PortletContext by o.a.j.CommonPortletServices.CPS_PORTLET_PREFERENCES_PROVIDER. 
See [1] for details.
  Probably #retrieveUserPreferences() and #storeUserPreferences() will be 
useful.
- Each portlet window object can be retrieved from the renderRequest by 
renderRequest.getAttribute(o.a.j.PortalReservedParameters.PORTLET_WINDOW_ATTRIBUTE);
- User name can be retrieved via renderRequest.getUserPrincipal().getName().

HTH,

Woonsan

[1] http://portals.apache.org/jetspeed-2/deployguide/guide-services.html

--- On Fri, 9/17/10, bhardage <[email protected]> wrote:

> From: bhardage <[email protected]>
> Subject: How would I make portlets with the same backing class display 
> different information?
> To: [email protected]
> Date: Friday, September 17, 2010, 7:37 PM
> 
> Hello,
> 
> This is a rather lengthy description so please bear with
> me.
> 
> I have a list with x number of items, and a page with x
> number of portlets.
> Each portlet on the page has the same backing class and
> access to my list,
> and what's shown changes depending on which list item is
> selected. The edit
> mode allows the user to select which item to display, and I
> store the item
> they selected in the preferences object behind the
> portlet.
> 
> As it stands, each portlet initially displays the first
> item in the list
> until a user edits the portlet and selects a different
> item. However, I'd
> like each portlet to show a different item initially.
> 
> It seems like I'll have to calculate which item to show
> based on position.
> If I have 2 columns and 6 rows then the item in column 2
> row 4 will show
> item 8 ((row - 1) * #columns + column). This works well
> except that, when
> the user starts moving the portlets around, the portlet
> values change with
> position.
> 
> I'd like to "lock in" the item selected initially, so it
> doesn't change with
> movement. Unfortunately, I really need to store the initial
> item selected
> (or the initial position) in the preferences object, but I
> can't do that in
> the doView function, and processAction isn't called until a
> portlet switches
> states.
> 
> I thought about just storing the initial choice in the
> session and reading
> it when the processAction function is called (giving it
> lower priority than
> the actual submitted choice). The problem with this is
> that, if the session
> invalidates before the user switches portlet modes, the
> selected item won't
> be stored.
> 
> My other thought was to somehow include the portlet's
> position as a variable
> in the portlet-preferences element of the portlet.xml file,
> but I don't even
> know if this is possible.
> 
> I guess another option would be to use my own preferences
> implementation,
> but I kind of see that as a last resort.
> 
> Does anyone have any ideas about how I might accomplish
> what I need?
> 
> Any help/suggestions are much appreciated.
> 
> Thanks,
> 
> B.J.
> 
> P.S. I'm using the Portlet 2.0 specification (though I'm
> not using events)
> and Jetspeed 2.1.
> -- 
> View this message in context: 
> http://old.nabble.com/How-would-I-make-portlets-with-the-same-backing-class-display-different-information--tp29740894p29740894.html
> Sent from the Jetspeed - User mailing list archive at
> Nabble.com.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
> 


      

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to