Request mapping question

[Rama Kesara <RK...@art.com>]

We have been used Wicket for developing our web applications so far and currently we are trying to tackle one issue where an optional language parameters comes in the url for all applications. We are trying to see how can we customize our applications to have a common page mapper or common processor which interprets the request first to identify if there is any language parameter that is being passed and if not just resolve the page usually however wicket does it.

Let me detail it further with an example. For example, if we have two web application say FirstApp and SecondApp that are running in our environment associated to their own contexts.

Now for FirstApp, lets say we have following mountPage option in that particular webapplication:
mountPage("/firstpage/${someinput}", FirstPage.class);

And for SecondApp, lets say we have following mountPage option in that particular webapplication:
mountPage("/secondpage/${someinput}", SecondPage.class);

Now say,
http://www.abcd.com/firstpage/xyz -> goes to First application and it resolves to that FirstPage and does whatever it is supposed to do
http://www.abcd.com/secondpage/xyz -> goes to Second application and it resolves to that SecondPage and does whatever it is supposed to do

Now if we have a optional language parameter in the request path, how can we handle request mapping for that case without altering those applications mount options.

http://www.abcd.com/fr/firstpage/xyz
http://www.abcd.com/es/firstpage/xyz

Now, I know that we can change mount options as follows and tackle that each application will expect an optional language param.

mountPage("/#{language}/firstpage/${someinput}", FirstPage.class);
mountPage("/#{language}/secondpage/${someinput}", SecondPage.class);

But is it possible to handle it before even the request comes to WicketFilter? If yes, can anyone share any thoughts or views on that. I am not looking to edit all webapplications and all page paths to edit and add that optional language param, instead if I can handle the request url before even wicketFilter tries to resolve that page.. it would help. Also, I am stressing if that can be a common level because we might have multiple applications coming up and we want to tackle that issue in a common place..

Any pointers will be of great help.. Appreciate you help in advance.

Thanks
Rama

Re: Request mapping question

[Rama Kesara <RK...@art.com>]

Thanks Martin, I will take a look and let you know.

Martin Grigorov <mg...@apache.org> wrote:


Hi,

Take a look at https://github.com/apache/wicket/tree/master/wicket-examples/src/main/java/org/apache/wicket/examples/requestmapper
and more specifically the usage of LocaleFirstMapper.

On Thu, Aug 16, 2012 at 10:19 PM, Rama Kesara <RK...@art.com> wrote:
> We have been used Wicket for developing our web applications so far and currently we are trying to tackle one issue where an optional language parameters comes in the url for all applications. We are trying to see how can we customize our applications to have a common page mapper or common processor which interprets the request first to identify if there is any language parameter that is being passed and if not just resolve the page usually however wicket does it.
>
> Let me detail it further with an example. For example, if we have two web application say FirstApp and SecondApp that are running in our environment associated to their own contexts.
>
> Now for FirstApp, lets say we have following mountPage option in that particular webapplication:
> mountPage("/firstpage/${someinput}", FirstPage.class);
>
> And for SecondApp, lets say we have following mountPage option in that particular webapplication:
> mountPage("/secondpage/${someinput}", SecondPage.class);
>
> Now say,
> http://www.abcd.com/firstpage/xyz -> goes to First application and it resolves to that FirstPage and does whatever it is supposed to do
> http://www.abcd.com/secondpage/xyz -> goes to Second application and it resolves to that SecondPage and does whatever it is supposed to do
>
> Now if we have a optional language parameter in the request path, how can we handle request mapping for that case without altering those applications mount options.
>
> http://www.abcd.com/fr/firstpage/xyz
> http://www.abcd.com/es/firstpage/xyz
>
> Now, I know that we can change mount options as follows and tackle that each application will expect an optional language param.
>
> mountPage("/#{language}/firstpage/${someinput}", FirstPage.class);
> mountPage("/#{language}/secondpage/${someinput}", SecondPage.class);
>
> But is it possible to handle it before even the request comes to WicketFilter? If yes, can anyone share any thoughts or views on that. I am not looking to edit all webapplications and all page paths to edit and add that optional language param, instead if I can handle the request url before even wicketFilter tries to resolve that page.. it would help. Also, I am stressing if that can be a common level because we might have multiple applications coming up and we want to tackle that issue in a common place..
>
> Any pointers will be of great help.. Appreciate you help in advance.
>
> Thanks
> Rama



--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Request mapping question

[Martin Grigorov <mg...@apache.org>]

Hi,

Take a look at https://github.com/apache/wicket/tree/master/wicket-examples/src/main/java/org/apache/wicket/examples/requestmapper
and more specifically the usage of LocaleFirstMapper.

On Thu, Aug 16, 2012 at 10:19 PM, Rama Kesara <RK...@art.com> wrote:
> We have been used Wicket for developing our web applications so far and currently we are trying to tackle one issue where an optional language parameters comes in the url for all applications. We are trying to see how can we customize our applications to have a common page mapper or common processor which interprets the request first to identify if there is any language parameter that is being passed and if not just resolve the page usually however wicket does it.
>
> Let me detail it further with an example. For example, if we have two web application say FirstApp and SecondApp that are running in our environment associated to their own contexts.
>
> Now for FirstApp, lets say we have following mountPage option in that particular webapplication:
> mountPage("/firstpage/${someinput}", FirstPage.class);
>
> And for SecondApp, lets say we have following mountPage option in that particular webapplication:
> mountPage("/secondpage/${someinput}", SecondPage.class);
>
> Now say,
> http://www.abcd.com/firstpage/xyz -> goes to First application and it resolves to that FirstPage and does whatever it is supposed to do
> http://www.abcd.com/secondpage/xyz -> goes to Second application and it resolves to that SecondPage and does whatever it is supposed to do
>
> Now if we have a optional language parameter in the request path, how can we handle request mapping for that case without altering those applications mount options.
>
> http://www.abcd.com/fr/firstpage/xyz
> http://www.abcd.com/es/firstpage/xyz
>
> Now, I know that we can change mount options as follows and tackle that each application will expect an optional language param.
>
> mountPage("/#{language}/firstpage/${someinput}", FirstPage.class);
> mountPage("/#{language}/secondpage/${someinput}", SecondPage.class);
>
> But is it possible to handle it before even the request comes to WicketFilter? If yes, can anyone share any thoughts or views on that. I am not looking to edit all webapplications and all page paths to edit and add that optional language param, instead if I can handle the request url before even wicketFilter tries to resolve that page.. it would help. Also, I am stressing if that can be a common level because we might have multiple applications coming up and we want to tackle that issue in a common place..
>
> Any pointers will be of great help.. Appreciate you help in advance.
>
> Thanks
> Rama



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org