>A couple questions:  Your generic page -- I just got back into
>extending pages (the T4 way).  I am putting my abstract or"base" pages
>in the /base directory.  This seems like the proper place to put them,
>right?

That's what I do as well

>2nd:  With an ApplicationScoped bean, is that per session or one for
>the whole application?  It seems like having one for the whole app
>would cause issues with one person receiving another person's error
>flag.  I guess I am confused a little--when say ASO, I think of it as
>existing for a current user's session only.  (Another person using the
>app would have no direct knowledge of the ASO)

I have often wondered why the annotation is @ApplicationState cuz it seems
to me it is just a session scoped bean. This is how we use it without any
problems. So your assumption seems correct to me. ASO is session scoped. If
I'm missing something here I would love to be corrected. 

Cheers,
Joost
-----Original Message-----
From: Daniel Jue [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 02, 2007 5:29 PM
To: Tapestry users
Subject: Re: T5 Strategy for redirecting due to any error

Ah!

CleanupRender is a place I had not thought of!   As long as the
"errors" wouldn't cause actual runtime exceptions (which I may not
catch because catching RTE is not enforced), I could just set this
"flag" and I can redirect/display something meaningful.

A couple questions:  Your generic page -- I just got back into
extending pages (the T4 way).  I am putting my abstract or"base" pages
in the /base directory.  This seems like the proper place to put them,
right?

2nd:  With an ApplicationScoped bean, is that per session or one for
the whole application?  It seems like having one for the whole app
would cause issues with one person receiving another person's error
flag.  I guess I am confused a little--when say ASO, I think of it as
existing for a current user's session only.  (Another person using the
app would have no direct knowledge of the ASO)

On 8/1/07, Joost Schouten <[EMAIL PROTECTED]> wrote:
> Daniel,
>
> I just setup a system where I have an ApplicationScoped bean hold a String
> authenticationDeniedMessage (could obviously be any error message). On my
> GenericPage which all my pages extend, I check on the @CleanupRender if
this
> String != null and if so, redirect to my AuthetnicationDenied page. This
> page renders the message in clears it on @CleanupRender so any subsequent
> request will work again. This setup allows me to deny access to a page at
> any point of my page lifecycle without Declerative or Runtime Exceptions.
>
> Cheers,
> Joost
>
> -----Original Message-----
> From: Daniel Jue [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 02, 2007 2:56 AM
> To: Tapestry users
> Subject: T5 Strategy for redirecting due to any error
>
> Hi, this is more a question of technique than an actual problem.
>
> Some use cases:
> Lets say I have code that throws a NPE.  I'd get a Tapestry error page
> that spills it's guts.  It must use some technique for redirecting to
> another page at any point (might be too deep in the framework to
> harness that power)
>
> Lets say I have another page that requires a user session (ASO) -- the
> OnActivate method would do the checking and redirect to a page from
> there.  Anyone can do this from OnActivate--so long as you know
> everything in the OnActivate() method, so it's not really interesting.
>
> Now lets say I have a page or component that checks a value that we
> could label as invalid, or we have a select component that can't be
> filled because a DB is down.
>
> Is there a way to redirect to another page at any point in the render
> process of a component or page?
>
> I think this would kind of fall along the lines of people who
> questioned how to replace the Tapestry error page with something more
> appropriate for the end user.  Except that I'd want to be able to
> explicitly call/forward to an arbitrary page when my code comes across
> something abnormal.
>
> Does anyone have ideas or strategies about this?
>
> Daniel Jue
>
> ---------------------------------------------------------------------
> 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]
>
>

---------------------------------------------------------------------
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