Hi Cosma,
I am sorry I did not understand the problem fully. Can you take the content
of the IFrame document and put it in the main page document in case of a
failure instead of doing a full page refresh?
Venkata
On 7/18/06, Cosma Colanicchia <[EMAIL PROTECTED]> wrote:
Venkata,
maybe I'm not getting your point, by in my script I'm trying to avoid
a "full page refresh". As I'm trying to keep my app as "session
timeout-proof" as possible, I use full client state saving and almost
all my managed bean are request scoped. Said that, I want the original
request parameters (so including the serialized component tree state)
to pass throught the login process, and because that was a PPR
requests I cannot simply load it as it was the main page (PPR response
seems to me to be potentially incomplete, only including the required
html elements and the code to replace them in the outer window). Even
knowing exactly what makes a request a "PPR" one, I'm not sure that it
is possible to safely revert it to a full request.
So my solution was to simply have the login page showed someway, but
without breaking the usual PPR process, so the popup that submit
itself again into the _pprIFRAME. I had no full success with it,
because sometimes after the login the original action (a list sort,
for example) doesn't get executed, and the user must click again. I've
not researched the reasons of this.
Regards
Cosma
2006/7/18, venkata guddanti <[EMAIL PROTECTED]>:
> Sorry I mean window.top.location :)
>
>
>
> On 7/18/06, venkata guddanti <[EMAIL PROTECTED]> wrote:
> >
> > Can't the checkPPR function do the following:
> >
> >
> > if ("_pprIFrame" == window.name) {
> >
> > var
> > replaceUrl = window.location.href;
> >
> > window.location.replace(replaceUrl);
> >
> > }
> >
> > to do a full page refresh?
> >
> > Venkata
> >
> >
> >
> > On 7/18/06, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
> > >
> > > I'll take a look at the thread, but have you thought about linking
> > > something in through the filter?
> > >
> > > Cosma Colanicchia wrote:
> > > > Scott,
> > > >
> > > > that would be the solution, but I haven't found a way to implement
it,
> > > > and I doubt that it exists. You can read the details in the thread
I
> > > > linked in my last reply.. anyway the problem is that the servlet
> > > > container, after a session timeout, forwards any requests to the
login
> > > > page *without* triggering any filter or servlet. So, there is just
no
> > > > way to "get in the middle" and abort the PPR request for a full
page
> > > > one. No hooks with servlets, filters, phaselisteners etc.
> > > >
> > > > The fact that the current implementation of PPR is based on hidden
> > > > IFRAMEs makes thing more difficult, because it assumes that the
> > > > returned page (the one loaded into the hidden iframe) will contain
the
> > > > logic to update the outer frame DOM. The user action only fires a
> > > > request with some "magic" parameters to activate PPR and then
forget
> > > > about it. No hooks on the page that invokes the PPR request to
"see"
> > > > what the response is. But when a session timeout occours, the
returned
> > > > page will be the login one and, of course, the PPR update logic
will
> > > > not be executed. Se no hooks in the PPR response logic neither..
> > > >
> > > > Due to the questionable design of container managed security (no
API),
> > > > I see only two solutions: the first is to put some special logic
on
> > > > the login page (my workaround), the other is to change the
> > > > implementation of PPR so that the "invoking page" script will not
> > > > forget about its request, but instead wait for the response, look
into
> > >
> > > > it and update the DOM. That logic could then also check if the
> > > > returned page is a "login" and take some action. This could be
> > > > obtained switching to XMLHttpRequest instead of the hidden IFRAME
to
> > > > perform PPR, and it seems that this will be done in a near future.
> > > >
> > > > Regards
> > > > Cosma
> > > >
> > > >
> > > > 2006/7/18, Scott O'Bryan <[EMAIL PROTECTED] >:
> > > >> Can't we just do a full-page refresh if the session is timed out?
> > > >>
> > > >> Cosma Colanicchia wrote:
> > > >> > There was a discussion about this problem, see this thread in
the
> > > >> > archives for the details:
> > > >> >
> > > >>
http://mail-archives.apache.org/mod_mbox/incubator-adffaces-dev/200606.mbox/browser
> > >
> > > >>
> > > >> >
> > > >> >
> > > >> > I've found a tricky workaround, that involves putting some
> > > javascript
> > > >> > in your login page to make it open itself in a popup window
when
> > > its
> > > >> > loaded in the ppr iframe:
> > > >> >
> > > >> > <script type="text/javascript">
> > > >> >
> > > >> > // NOTE this is a workaround for an issue when using
Trinidad
> > > >> > // PPR requests and container-managed security
> > > >> >
> > > >> > // This is a temporary workaround while waiting for Trinidad
to
> > > use
> > > >> > // XmlHTTPRequest instead of hidden IFRAMEs for partial page
> > > >> rendering
> > > >> >
> > > >> > function checkPPR() {
> > > >> > var loginForm = document.getElementById("loginForm");
> > > >> > if ("_pprIFrame" == window.name) {
> > > >> > // Reload myself in a window with a fixed name
> > > >> > var loginWindow = window.open(window.location,
> > > >> "_pprLoginWindow",
> > > >> > "menubar=0,resizable=1,width=350,height=250");
> > > >> > loginForm.location = window.location;
> > > >> > }
> > > >> > if ("_pprLoginWindow" == window.name) {
> > > >> > // Now I'm in the window, set the target back to the
hidden
> > > >> iframe
> > > >> > loginForm.target = "_pprIFrame";
> > > >> > }
> > > >> > }
> > > >> >
> > > >> > function checkPPRClose() {
> > > >> > // This script trigger also when the login is wrong.. so
the
> > > >> > // "login failed" page must also do something to show
> > > >> > // itself outside of the hidden iframe.
> > > >> > if ("_pprLoginWindow" == window.name) {
> > > >> > // The timeout is required to allow performing
> > > >> > // the form submit before closing the window
> > > >> > setTimeout('window.close()', 3000);
> > > >> > }
> > > >> > }
> > > >> >
> > > >> > </script>
> > > >> > </head>
> > > >> > <body onload="checkPPR();">
> > > >> > <!-- standard action and field names for contained managed
> > > >> security -->
> > > >> > <form id="loginForm" method="POST" action="j_security_check"
> > > >> > onsubmit="checkPPRClose();">
> > > >> >
> > > >> >
> > > >> > Far from perfect, but it allows the user to escape from the
lock
> > > that
> > > >> > would occours otherwise. If you come up with a better solution
> > > please
> > > >> > share it.
> > > >> >
> > > >> >
> > > >> > regards
> > > >> > Cosma
> > > >> >
> > > >> > 2006/7/18, Jeantine Mankelow <[EMAIL PROTECTED]>:
> > > >> >> We are using adf's ppr features in our web based
product. This
> > > all
> > > >> >> works fine until the session times out and the users tries to
do
> > > >> >> something which would cause a ppr on the already loaded
page. To
> > > the
> > > >> >> user if appears as if nothing happens, when in fact what is
> > > >> happening is
> > > >> >> the login page is getting rendered in the iFrame.
> > > >> >>
> > > >> >> Any ideas on how we can direct the page the user can see to
the
> > > login
> > > >> >> page?
> > > >> >>
> > > >> >> Thanks,
> > > >> >> Jeantine
> > > >> >>
> > > >> >
> > > >>
> > > >>
> > > >
> > >
> > >
> >
>
>
