portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glenn R. Golden" <ggol...@umich.edu>
Subject Re: panels in portlets conflict with Maximize
Date Tue, 07 May 2002 01:11:56 GMT
Still More...

I think that the idea of checking for the presence of the "template" in 
the request might work to be the criteria of when NOT to maximize... but 
I don't like it.  I might work, but it's not based on any solid 

So, here's another approach.  Lets "fix" maximize.

Right now, maximize is handled in the session validator.  Maximize is 
really a property of the portal page, for the user (session) viewing 
it.  For this user, now it's maximized, now we show the entire page, 
etc.  The page session state is modified by the Maxmize and Restore 

The display of the portal page is handled by our "home" screen 
template.  I propose that we modify home.vm so that it detects the 
presence of maximized in the page's session state.  If not there, it 
does the entire page, or pane.  If there, it does just that portlet.  
This merges the maximize template with the home template.

This is a better solution, because when we send in a request and that 
request ends up using the "home" (default) screen, then maximize comes 
into play.  If we send in a request that ends up using a different 
screen / layout (such as will be for the panel's iframes using 
"content"), then the maximize naturally doesn't come into play, since 
that's a feature of the "home" screen.

Both maximize and home are very simple vm files, and the combined 
version should be very clean.

What say you all?

On Monday, May 6, 2002, at 02:42  PM, Glenn Golden wrote:

> More...
> What does it mean to have a "js_peid" parameter in the request?  Is 
> this a
> request "For" the portlet element?  No. It's still a jetspeed request, 
> but
> the "js_peid" is a standard way that many actions (etc) will look for
> information identifying which portlet they should act upon (Maximize,
> Restore, etc).
> So, having a js_peid in the request should *not* cancle out the maximize
> behavior...
> That leaved us only detection of the "template" in the request - if a
> template is specifically requested, we will use it, and not add one 
> (such as
> to handl Maxmize).
> We need to make sure that when we form a url, we don't put in the 
> template
> if we don't have to.  We should never see "template/home", as this is 
> the
> default.
> I'm off to try this one out...
> - Glenn
> --------------------------------------------
> Glenn R. Golden, Systems Research Programmer
> University of Michigan School of Information
> ggolden@umich.edu               734-615-1419
> --------------------------------------------
>> -----Original Message-----
>> From: Glenn Golden [mailto:ggolden@umich.edu]
>> Sent: Monday, May 06, 2002 1:17 PM
>> To: Jetspeed-Dev (jetspeed-dev@jakarta.apache.org)
>> Subject: panels in portlets conflict with Maximize
>> A "panel", let us accept as a definition for now, is a
>> independently updatable area of a portlet's display.  We can
>> implement this by making the main portlet spit out iframes
>> for each panel section, mixed with any other HTML we want for
>> the portlet.
>> The "src=" for the panel iframe is a request back to Jetspeed
>> to render a sub-section of the portlet.  This subsection
>> must be portlet (sub-) content only, no control, no page
>> layout.  So, the request needs to identify the
>> following:
>> js_peid/<id> - to id the portlet involved (used by the
>> content.vm templates) panel/<panel id> - to tell the portlet
>> which sub-section to display (used by the portlets)
>> template/content - to tell jetspeed to do some special
>> formatting (this is our new "content" templates)
>> The panel names can be whatever the portlet wants them to be.
>> So, for example, we might have this:
>> http://chefproject.org/jetspeed/portal/js_peid/304/panel/List/
>> template/conte
>> nt
>> This works just fine... Until we maximize this portlet.
>> The way Maximize.java "works", along with the
>> JetspeedSessionValidator, is to store the js_peid in the
>> user's session's get/setTemp() as "js_peid", and if that
>> value is present when any request comes in from that user /
>> session, to change to the Maximize template.
>> Consider what we need when we maximize a  "paneled" portlet.
>> The first request, for the entire portlet, needs to do the
>> standard maximize thing. The subsequent requests for each
>> iframe need to be processed without any modifications for maximize.
>> What is happening now is that the maximize template is used
>> instad of the "content" template as requested.  The result is
>> we get each panel of the maximized portlet, as expected, but
>> each panel has the entire jetspeed screen navigation and
>> control, which is not what we want.
>> So...
>> I don't like how maximize works, anyway, and want to change
>> it to use the new StateManager, and consider the maximized
>> state as part of the portal page's session state for this user.
>> But this won't help here, because what we really need is to
>> change JetspeedSessionValidator.  It must recognize when the
>> page is set to maximize something, and modify the request for
>> only the page - level requests, not the iframe - panel level requests.
>> There are two situations: the first time maximize is invoked
>> (in which case the Maximize action is called), and subsequent
>> requests for the page (in which case no maximize action is
>> called, just the standard page request).
>> In the cases where action=Maximize is in the request, the
>> Maximize action can take care of things.
>> In the normal URL to the page case, JetspeedSessionValidator
>> needs to distinguish between the URL to the page and those to
>> a portlet.
>> I propose that if JetspeedSessionValidator sees the "js_peid"
>> in the request, then it can assume it is a request to a
>> portal element, not the entire page.  Only when this is
>> absent will it change the request to use the "maximize" template.
>> We can also look for an explicit "template" in the request,
>> and leave these alone as well.
>> I'll be testing this today and seeing how it works... Please, comment!
>> Thanks.
>> - Glenn
>> --------------------------------------------
>> Glenn R. Golden, Systems Research Programmer
>> University of Michigan School of Information
>> ggolden@umich.edu               734-615-1419
>> --------------------------------------------
>> --
>> To unsubscribe, e-mail:
>> <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
>> For
>> additional commands,
>> e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
> --
> To unsubscribe, e-mail:   <mailto:jetspeed-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:jetspeed-dev-
> help@jakarta.apache.org>

- Glenn

Glenn R. Golden    Systems Research Programmer
School of Information             University of Michigan
ggolden@umich.edu                            734-615-1419

To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>

View raw message