It's not for authorization... It's for running reports. I realize that the Wicket stratagy is to work with components, but in this instance its not a practical option. The business requirement dictates that from any page in the application a parameter can be added to the url (by means of external systems) that will route the application (Wicket) to the appropriate page for processing. I'm over simplifying the scenario, but that is the jist of it.
I hope to convert this process to a webservice to be consumed by the internal Wicket application in the near future, but there are some dependencies with some of the external applications that prevent us from doing so at this time. -----Original Message----- From: Eelco Hillenius [mailto:[EMAIL PROTECTED] Sent: Thursday, November 08, 2007 1:38 PM To: users@wicket.apache.org Subject: Re: Wicket & Servlet Filters On Nov 8, 2007 10:26 AM, William Hoover <[EMAIL PROTECTED]> wrote: > 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? Try to forget how other frameworks do things and look for solutions on a case by case basis. > Say you have a simple task of checking for a parameter and/or session object > and redirecting to specified Wicket pages, accordingly? For what purpose? If it is for authorization, we have authorization strategies: see wicket-auth for an example project. Furthermore, you would not be checking for a parameter since the idea with using Wicket is that you work with components/ objects, not request parameters. Eelco --------------------------------------------------------------------- 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]
