You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Andrew Strickland <st...@gmail.com> on 2008/01/22 20:58:50 UTC
Desktop mode and SupportsHeaderPhase Problem
Hi everyone,
I was initially working this issue with Woonsan but wanted to start a new
thread because we solved the initial problem but I have since uncovered a
new and more complex issue.
The first time a page (notice I did not say, my page) is rendered in
/desktop mode I believe the Jetspeed engine does probably invoke the
SupportsHeaderPhase aggregator. However, my portlet is not on the page that
was requested and rendered and therefor Its doHeader method is not invoked
and the content contributed to the head. Then, when we switch pages (still
in /desktop mode) from the initial page requested to the page that has my
portlet on it, this request is done via AJAX and thus does not re-render the
page or make a trip to the server and so skips the header aggregation phase
and thus my portlet does not have it's doHeader method called and content
contributed to the head. If the page is then refreshed either by invoking
some action on a portlet or just by hitting F5...the server triggers the
header aggregation phase and my portlet's doHeader method is invoked and the
content added to the head.
This is occuring in both my customized Jetspeed 2.1.2 deployment and the
fresh 2.1.3 Jetspeed distro that I used to solve the problem from the last
thread. I do not believe this problem is at all related in our
configuration of portal xml files.
Is this something the Jetspeed team is aware of? If so, what resolutions
are in the pipeline and what is the timeline? If not, I have thought of
several ways to work around the issue, both involve modifications to
Jetspeed.
We can think of a couple ways to solve this:
1) Set a property in the PSML of the page that contains the portlet that
needs header phase support. Whatever reads the PSML will be modified to
look at this property to see if there are any portlets on the page that need
header phase support. If a portlet needs header phase support the
javascript that is asynchronously requesting the portlet content will
instead be directed to refresh the page and to add a parameter to the URL
like: "your-portlet-that-requires-header-support=handled". This will
prevent subsequent page requests from needlessly refreshing the page since
the content has already been added to the head.
2) Same as above except instead of adding a parameter to the URL we could
set an attribute in the javascript itself to remember whether or not it has
refreshed the page for the portlet that requires header phase support.
Option 1 allows for easier debugging since we could just inspect the URL,
but I think either would work just fine for us. What do you think?
Regards,
Andy
Re: Desktop mode and SupportsHeaderPhase Problem
Posted by Andrew Strickland <st...@gmail.com>.
Thanks for the response. I guess, for now, our solution is just going to be
to disallow third-party javascript from portlets (via content guidelines)
and only allow the use of resources either inline in the portlet's content
or that is provided by Jetspeed (dojo). The portal performs much faster in
desktop mode and we don't want to have to refresh the page every time they
change pages.
When the portlet 2.0 spec comes out will it present any solutions to this
problem?
Andy
On Jan 22, 2008 5:57 PM, Steve Milek <s....@comcast.net> wrote:
> Andrew,
>
> There is a setting that will disable ajax page navigation. In
> assembly/headtag.xml, find the "DesktopConfiguration" bean and set the
> entry
> "page.ajaxnavigation" to false.
>
> We haven't settled on a proper solution to this problem, but the goal is
> to
> make it work without requiring a new property in psml or elsewhere.
>
>
>
> Steve
>
>
> -----Original Message-----
> From: Andrew Strickland [mailto:strickla@gmail.com]
> Sent: Tuesday, January 22, 2008 12:59 PM
> To: Jetspeed
> Subject: Desktop mode and SupportsHeaderPhase Problem
>
> Hi everyone,
>
> I was initially working this issue with Woonsan but wanted to start a new
> thread because we solved the initial problem but I have since uncovered a
> new and more complex issue.
>
> The first time a page (notice I did not say, my page) is rendered in
> /desktop mode I believe the Jetspeed engine does probably invoke the
> SupportsHeaderPhase aggregator. However, my portlet is not on the page
> that
> was requested and rendered and therefor Its doHeader method is not invoked
> and the content contributed to the head. Then, when we switch pages
> (still
> in /desktop mode) from the initial page requested to the page that has my
> portlet on it, this request is done via AJAX and thus does not re-render
> the
> page or make a trip to the server and so skips the header aggregation
> phase
> and thus my portlet does not have it's doHeader method called and content
> contributed to the head. If the page is then refreshed either by invoking
> some action on a portlet or just by hitting F5...the server triggers the
> header aggregation phase and my portlet's doHeader method is invoked and
> the
> content added to the head.
>
> This is occuring in both my customized Jetspeed 2.1.2 deployment and the
> fresh 2.1.3 Jetspeed distro that I used to solve the problem from the last
> thread. I do not believe this problem is at all related in our
> configuration of portal xml files.
>
> Is this something the Jetspeed team is aware of? If so, what resolutions
> are in the pipeline and what is the timeline? If not, I have thought of
> several ways to work around the issue, both involve modifications to
> Jetspeed.
>
> We can think of a couple ways to solve this:
>
> 1) Set a property in the PSML of the page that contains the portlet that
> needs header phase support. Whatever reads the PSML will be modified to
> look at this property to see if there are any portlets on the page that
> need
> header phase support. If a portlet needs header phase support the
> javascript that is asynchronously requesting the portlet content will
> instead be directed to refresh the page and to add a parameter to the URL
> like: "your-portlet-that-requires-header-support=handled". This will
> prevent subsequent page requests from needlessly refreshing the page since
> the content has already been added to the head.
>
> 2) Same as above except instead of adding a parameter to the URL we could
> set an attribute in the javascript itself to remember whether or not it
> has
> refreshed the page for the portlet that requires header phase support.
>
> Option 1 allows for easier debugging since we could just inspect the URL,
> but I think either would work just fine for us. What do you think?
>
> Regards,
> Andy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
RE: Desktop mode and SupportsHeaderPhase Problem
Posted by Steve Milek <s....@comcast.net>.
Andrew,
There is a setting that will disable ajax page navigation. In
assembly/headtag.xml, find the "DesktopConfiguration" bean and set the entry
"page.ajaxnavigation" to false.
We haven't settled on a proper solution to this problem, but the goal is to
make it work without requiring a new property in psml or elsewhere.
Steve
-----Original Message-----
From: Andrew Strickland [mailto:strickla@gmail.com]
Sent: Tuesday, January 22, 2008 12:59 PM
To: Jetspeed
Subject: Desktop mode and SupportsHeaderPhase Problem
Hi everyone,
I was initially working this issue with Woonsan but wanted to start a new
thread because we solved the initial problem but I have since uncovered a
new and more complex issue.
The first time a page (notice I did not say, my page) is rendered in
/desktop mode I believe the Jetspeed engine does probably invoke the
SupportsHeaderPhase aggregator. However, my portlet is not on the page that
was requested and rendered and therefor Its doHeader method is not invoked
and the content contributed to the head. Then, when we switch pages (still
in /desktop mode) from the initial page requested to the page that has my
portlet on it, this request is done via AJAX and thus does not re-render the
page or make a trip to the server and so skips the header aggregation phase
and thus my portlet does not have it's doHeader method called and content
contributed to the head. If the page is then refreshed either by invoking
some action on a portlet or just by hitting F5...the server triggers the
header aggregation phase and my portlet's doHeader method is invoked and the
content added to the head.
This is occuring in both my customized Jetspeed 2.1.2 deployment and the
fresh 2.1.3 Jetspeed distro that I used to solve the problem from the last
thread. I do not believe this problem is at all related in our
configuration of portal xml files.
Is this something the Jetspeed team is aware of? If so, what resolutions
are in the pipeline and what is the timeline? If not, I have thought of
several ways to work around the issue, both involve modifications to
Jetspeed.
We can think of a couple ways to solve this:
1) Set a property in the PSML of the page that contains the portlet that
needs header phase support. Whatever reads the PSML will be modified to
look at this property to see if there are any portlets on the page that need
header phase support. If a portlet needs header phase support the
javascript that is asynchronously requesting the portlet content will
instead be directed to refresh the page and to add a parameter to the URL
like: "your-portlet-that-requires-header-support=handled". This will
prevent subsequent page requests from needlessly refreshing the page since
the content has already been added to the head.
2) Same as above except instead of adding a parameter to the URL we could
set an attribute in the javascript itself to remember whether or not it has
refreshed the page for the portlet that requires header phase support.
Option 1 allows for easier debugging since we could just inspect the URL,
but I think either would work just fine for us. What do you think?
Regards,
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org