You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by gr...@intellicare.com on 2005/10/14 20:28:53 UTC
[Shale] Help - wonky prerender() call!
I have been trying all day to understand exactly where and when Shale
injects into the JSF life cycle and I think i'm almost there..:) But I do
have one question which reads rather long, so please bear with me.
Here's what I do with my Tiles+Shale webapp:
1. Acces it via: http://www.myContext/
index.jsp is wired to forward to logon.faces which in turn displays a
tiles def for /login. which displays my logon page.
debug stmts I get during this access are:
in init of login! and ispostback is: false
in prerender of login! and ispostback is: false
Makes perfect sense.
2. Next I authenticate by submitting the logon page.
Backing bean for logon is LogActions and LogActions.logon() returns the
String "authenticated" which is mapped in faces-config to /worklist.jsp
debug stmts I get during this whole procedure are:
in init of login! and ispostback is: true
in preprocess of login! and ispostback is: true
in init of worklist! and ispostback is: false
in prerender of worklist! and ispostback is: false
Again, fine so far.
3. Next I click on logoff and this is where stuff gets goofy.
Logoff link points to "logon.logoff". LogActions.logoff() does some stuff
and then returns "unauthenticated" which is mapped in faces-config.xml to
/failure.jsp which in turn displays a tiles def for /login - which again
displays my logon page fine.
But see what my debug statements say:
in init of worklist! and ispostback is: true
in preprocess of worklist! and ispostback is: true
in prerender of worklist! and ispostback is: true
The last statement is what i don't get. According to
http://struts.apache.org/shale/features.html#view this is the "Postback
processed by page A, which then navigates to page B" case of processing
where worklist.jsp is "A" and logon.jsp is "B".
So my thought is that third statement should read:
in prerender of login! and ispostback is: false
So why is prerender of worklist() being called? Can anybody shed some
light on this?
Thanks very much in advance!
Geeta
Re: [Shale] Help - wonky prerender() call!
Posted by gr...@intellicare.com.
Wendy Smoak <ja...@wendysmoak.com> wrote on 10/14/2005 03:27:30 PM:
> From: <gr...@intellicare.com>
>
> > Wendy, I am currently using eclipse's built-in debugger to step into
the
> > code. Would you recommend something else?
>
> No... your original message sounded like you were just looking at the
log
> file output.
Yes, that *would* be a sad thing..:)
Right after I sent that, you posted about setting breakpoints.
> So, never mind. :)
>
> --
> Wendy
>
Geeta
Re: [Shale] Help - wonky prerender() call!
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: <gr...@intellicare.com>
> Wendy, I am currently using eclipse's built-in debugger to step into the
> code. Would you recommend something else?
No... your original message sounded like you were just looking at the log
file output. Right after I sent that, you posted about setting breakpoints.
So, never mind. :)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale] Help - wonky prerender() call!
Posted by gr...@intellicare.com.
Wendy Smoak <ja...@wendysmoak.com> wrote on 10/14/2005 03:12:36 PM:
> From: <gr...@intellicare.com>
>
> >I have been trying all day to understand exactly where and when Shale
> > injects into the JSF life cycle and I think i'm almost there..:)
>
> By looking at the log files? Have you stepped through the code in a
> debugger? After you get past the initial setup, it will save you *so*
much
> time. If you don't already have a favorite, ask me about JSwat and
Tomcat.
> :)
Wendy, I am currently using eclipse's built-in debugger to step into the
code. Would you recommend something else?
> --
> Wendy Smoak
>
Geeta
Re: [Shale] Help - wonky prerender() call!
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: <gr...@intellicare.com>
>I have been trying all day to understand exactly where and when Shale
> injects into the JSF life cycle and I think i'm almost there..:)
By looking at the log files? Have you stepped through the code in a
debugger? After you get past the initial setup, it will save you *so* much
time. If you don't already have a favorite, ask me about JSwat and Tomcat.
:)
--
Wendy Smoak
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale] Help - wonky prerender() call! - SOLVED :)
Posted by gr...@intellicare.com.
Since I always seem to be asking questions and receiving help, I thought I
would let you know how I finally solved this problem.
What was wrong was in the naming of my jsps (the view-ids). I changed my
faces-config.xml from:
<navigation-case>
<from-outcome>loggedOff</from-outcome>
<to-view-id>/failure.jsp</to-view-id>
</navigation-case>
to
<navigation-case>
<from-outcome>loggedOff</from-outcome>
<to-view-id>/logon.jsp</to-view-id>
</navigation-case>
The rules for "registration" of the backing bean to a jsp/view-id are
given in detail in the javadocs for ViewController:
http://people.apache.org/~craigmcc/shale-core-javadocs/. Also, there are
examples in DefaultControllerMapper.java in the source. For example, I
have a managed bean called logon and hence setting the view-id as
/logon.jsp marries them together.. (I hope I've got that right!).
Clearly, unless the naming rules are strictly followed (see gory details
again in DefaultViewControllerMapper.java), Shale cannot be expected to
satisfy its contract.
So, I guess as always, the rule is: read the documentation. And if that
doesn't help, read the code..:)
Regards,
Geeta
Re: [Shale] Help - wonky prerender() call!
Posted by gr...@intellicare.com.
craigmcc@gmail.com wrote on 10/14/2005 02:51:05 PM:
> On 10/14/05, gramani@intellicare.com <gr...@intellicare.com> wrote:
> >
> > 3. Next I click on logoff and this is where stuff gets goofy.
> > Logoff link points to "logon.logoff". LogActions.logoff() does some
stuff
> > and then returns "unauthenticated" which is mapped in faces-config.xml
to
> > /failure.jsp which in turn displays a tiles def for /login - which
again
> > displays my logon page fine.
> > But see what my debug statements say:
> >
> > in init of worklist! and ispostback is: true
> > in preprocess of worklist! and ispostback is: true
> > in prerender of worklist! and ispostback is: true
> >
> > The last statement is what i don't get. According to
> > http://struts.apache.org/shale/features.html#view this is the
"Postback
> > processed by page A, which then navigates to page B" case of
processing
> > where worklist.jsp is "A" and logon.jsp is "B".
> > So my thought is that third statement should read:
> >
> > in prerender of login! and ispostback is: false
> >
> > So why is prerender of worklist() being called? Can anybody shed some
> > light on this?
> > Thanks very much in advance!
> > Geeta
> >
>
> The implication of this sequence of events is that the navigation
requested
> by "unauthenticated" did not actually happen, so it's redisplaying the
same
> page again. Are you sure you've got the navigation rules set up
correctly,
> so that this navigation should actually fire?
>
> It might also be useful to experiment with a case where worklist.jsp is
just
> a simple JSP page and not something with Tiles in it, just to make sure
> that's not part of the problem.
So here's what i did:
Changed worklist.jsp to a page with no tiles in it. Changed
LogActions.logoff() to return "logOff" which is mapped in faces-config.xml
to a (non-tiles) page called failure1.jsp. Cleaned out work directory,
cleaned, rebuilt blah-blah.. Then went through the steps again: Bring up
index.jsp, then log on, then logout. I see the new failure1.jsp so i know
the forwarding happened correctly. But the last piece stays wonky:
prerender() of worklist is still being called but prereder of logon is
not.
Only thing I didn't do was change *all* my pages to non-tiles pages -
which is the only other thing I can think of.. Kinda sad since I was
excited thinking I'd *finally* understood something about Shale correctly.
ah well..
>
> Craig
>
Geeta
Re: [Shale] Help - wonky prerender() call!
Posted by gr...@intellicare.com.
craigmcc@gmail.com wrote on 10/14/2005 02:51:05 PM:
> >
>
> The implication of this sequence of events is that the navigation
requested
> by "unauthenticated" did not actually happen, so it's redisplaying the
same
> page again. Are you sure you've got the navigation rules set up
correctly,
> so that this navigation should actually fire?
Hey no kidding, I actually thought of this :) and double checked my
faces-config.xml (case sensitivity and all) and I am quite sure not only
that "unauthenticated" is in fact what the logoff method returns and that
it is mapped to /failure.jsp
>
> It might also be useful to experiment with a case where worklist.jsp is
just
> a simple JSP page and not something with Tiles in it, just to make sure
> that's not part of the problem.
and yuk, I did think that tiles could be part of the problem too - though
I *really* don't want that to be the case..(:(. Along these lines, when I
read about the various times when preprocess() etc. get called, it seems
like words like "the view id" and "the view" and "the jsp" and "the
backing bean" are all used interchangably. Which is ok; i remember you
telling us jsp<->backing bean is a 1:1 relationship. Fine. But do you
"calculate" what the jsp/bean are (to decide what is A and what is B, for
instance during a "postback from page A to page B" using the mappings in
faces-config.xml? Because that is how I did it: logon page -> worklist
page -> logoff page. Hence beans are LogActionBean, WorklistBean,
LogAction bean. (Tiles makes the urls wierd but that should not be the way
things are calculated right?)
>
> Craig
>
> --
Re: [Shale] Help - wonky prerender() call!
Posted by Craig McClanahan <cr...@apache.org>.
On 10/14/05, gramani@intellicare.com <gr...@intellicare.com> wrote:
>
> 3. Next I click on logoff and this is where stuff gets goofy.
> Logoff link points to "logon.logoff". LogActions.logoff() does some stuff
> and then returns "unauthenticated" which is mapped in faces-config.xml to
> /failure.jsp which in turn displays a tiles def for /login - which again
> displays my logon page fine.
> But see what my debug statements say:
>
> in init of worklist! and ispostback is: true
> in preprocess of worklist! and ispostback is: true
> in prerender of worklist! and ispostback is: true
>
> The last statement is what i don't get. According to
> http://struts.apache.org/shale/features.html#view this is the "Postback
> processed by page A, which then navigates to page B" case of processing
> where worklist.jsp is "A" and logon.jsp is "B".
> So my thought is that third statement should read:
>
> in prerender of login! and ispostback is: false
>
> So why is prerender of worklist() being called? Can anybody shed some
> light on this?
> Thanks very much in advance!
> Geeta
>
The implication of this sequence of events is that the navigation requested
by "unauthenticated" did not actually happen, so it's redisplaying the same
page again. Are you sure you've got the navigation rules set up correctly,
so that this navigation should actually fire?
It might also be useful to experiment with a case where worklist.jsp is just
a simple JSP page and not something with Tiles in it, just to make sure
that's not part of the problem.
Craig
Re: [Shale] Help - wonky prerender() call!
Posted by gr...@intellicare.com.
craigmcc@gmail.com wrote on 10/14/2005 02:58:10 PM:
> On 10/14/05, gramani@intellicare.com <gr...@intellicare.com> wrote:
> >
> > "David G. Friedman" <hu...@ix.netcom.com> wrote on 10/14/2005
02:51:13
> > PM:
> >
> > > If you are doing a logout, wouldn't it be quicker to do an
> > immediate="true"
> > > along with your action invocation? Then you could skip the other
> > phases.
> > > It is in your logout/logoff after all, right?
> >
> > Oh, I guess that is an idea... mayeb I will try it but my question
still
> > remains I guess..:)
>
>
> Actually, it's a pretty good idea ... if your logout button is *not*
> immediate, then any validation rules on that page will still be
executed.
> And, if any of those validations fail, you'd be returned to the same
page
> again instead of executing the logout action.
No, that's what is wierd. I have breakpoints set and the
LogActions.logoff() method is ceratinly called..
> Craig
>
Geeta
Re: [Shale] Help - wonky prerender() call!
Posted by Craig McClanahan <cr...@apache.org>.
On 10/14/05, gramani@intellicare.com <gr...@intellicare.com> wrote:
>
> "David G. Friedman" <hu...@ix.netcom.com> wrote on 10/14/2005 02:51:13
> PM:
>
> > If you are doing a logout, wouldn't it be quicker to do an
> immediate="true"
> > along with your action invocation? Then you could skip the other
> phases.
> > It is in your logout/logoff after all, right?
>
> Oh, I guess that is an idea... mayeb I will try it but my question still
> remains I guess..:)
Actually, it's a pretty good idea ... if your logout button is *not*
immediate, then any validation rules on that page will still be executed.
And, if any of those validations fail, you'd be returned to the same page
again instead of executing the logout action.
>
> > -David, all talk, just theories.
> >
>
> Geeta - Theory is good :)
Craig
RE: [Shale] Help - wonky prerender() call!
Posted by gr...@intellicare.com.
"David G. Friedman" <hu...@ix.netcom.com> wrote on 10/14/2005 02:51:13
PM:
> If you are doing a logout, wouldn't it be quicker to do an
immediate="true"
> along with your action invocation? Then you could skip the other
phases.
> It is in your logout/logoff after all, right?
Oh, I guess that is an idea... mayeb I will try it but my question still
remains I guess..:)
>
> -David, all talk, just theories.
>
Geeta - Theory is good :)
RE: [Shale] Help - wonky prerender() call!
Posted by "David G. Friedman" <hu...@ix.netcom.com>.
If you are doing a logout, wouldn't it be quicker to do an immediate="true"
along with your action invocation? Then you could skip the other phases.
It is in your logout/logoff after all, right?
-David, all talk, just theories.
-----Original Message-----
From: gramani@intellicare.com [mailto:gramani@intellicare.com]
Sent: Friday, October 14, 2005 2:29 PM
To: user@struts.apache.org
Subject: [Shale] Help - wonky prerender() call!
I have been trying all day to understand exactly where and when Shale
injects into the JSF life cycle and I think i'm almost there..:) But I do
have one question which reads rather long, so please bear with me.
Here's what I do with my Tiles+Shale webapp:
1. Acces it via: http://www.myContext/
index.jsp is wired to forward to logon.faces which in turn displays a
tiles def for /login. which displays my logon page.
debug stmts I get during this access are:
in init of login! and ispostback is: false
in prerender of login! and ispostback is: false
Makes perfect sense.
2. Next I authenticate by submitting the logon page.
Backing bean for logon is LogActions and LogActions.logon() returns the
String "authenticated" which is mapped in faces-config to /worklist.jsp
debug stmts I get during this whole procedure are:
in init of login! and ispostback is: true
in preprocess of login! and ispostback is: true
in init of worklist! and ispostback is: false
in prerender of worklist! and ispostback is: false
Again, fine so far.
3. Next I click on logoff and this is where stuff gets goofy.
Logoff link points to "logon.logoff". LogActions.logoff() does some stuff
and then returns "unauthenticated" which is mapped in faces-config.xml to
/failure.jsp which in turn displays a tiles def for /login - which again
displays my logon page fine.
But see what my debug statements say:
in init of worklist! and ispostback is: true
in preprocess of worklist! and ispostback is: true
in prerender of worklist! and ispostback is: true
The last statement is what i don't get. According to
http://struts.apache.org/shale/features.html#view this is the "Postback
processed by page A, which then navigates to page B" case of processing
where worklist.jsp is "A" and logon.jsp is "B".
So my thought is that third statement should read:
in prerender of login! and ispostback is: false
So why is prerender of worklist() being called? Can anybody shed some
light on this?
Thanks very much in advance!
Geeta
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org