So in theory it can be accomplished, but is not recommended to do so... What is the common practice when dealing with wicket related data in a servlet filter? Say you have a simple task of checking for a parameter and/or session object and redirecting to specified Wicket pages, accordingly? It doesn't seem natural to handle this type of logic outside the scope of the Wicket API. I guess this is what I'm attempting to avoid :)
-----Original Message----- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Thursday, November 08, 2007 12:00 PM To: [email protected] Subject: Re: Wicket & Servlet Filters in the wicket world components have overridable listeners for different phases, so you would override it just for components that need different handling. we are not huge fans of these global/all-penetrating listeners. although in some cases we have done so, we have a component instantiation listener and a global before render listener. but so far that is all iirc. -igor On 11/8/07, William Hoover <[EMAIL PROTECTED]> wrote: > Well, I was thinking more in lines of a request listener (similar to a JSF > phase listener). As Wicket enters internal phases of execution a listener can > be added to perform some operations on the event. Just thought it would be > convenient to do something like this in the Wicket world :) > > -----Original Message----- > From: Igor Vaynberg [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 08, 2007 11:51 AM > To: [email protected] > Subject: Re: Wicket & Servlet Filters > > > wicket is a UI framework, handling servlet filters is a bit outside its scope > :) > > -igor > > > On 11/8/07, William Hoover <[EMAIL PROTECTED]> wrote: > > Is there a wicket way to handle servlet filters internally in the API or is > > the recomended method just to use typical servlet filters? > > > > > > --------------------------------------------------------------------- > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
