You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Brian Deterling <br...@gmail.com> on 2009/06/22 23:32:55 UTC

Re: Best practices to trigger serverside event methods from javascript?

I have a similar scenario. I want the user to be able to do a search and end
up at a nice url like /search/term. However, if their session times out, I'd
like to capture the original url, wait for them to log back in (or log in
automatically via cookie), and then redirect them to the original url. Since
forms use POST, I can't do that unless I use a non-Tapestry form or use
onclick to build the url but then if they enter a space or other invalid
character in the search term, the url isn't encoded correctly for Tapestry.
Someone posted a client-side encoder in
https://issues.apache.org/jira/browse/TAP5-637 so that's one option.
In
my case, I did as Howard suggested and captured that scenario in my
dispatcher, encoded the search
term into a new url, and did a redirect.

Brian

On Mon, May 25, 2009 at 4:15 AM, Joost Schouten (mailing lists) <
joost_ml@jsportal.com> wrote:

> I believe the encoding is fairly simple and shouldn't be too hard to
> do on the client. if there is a wider need for it, you could consider
> proposing a patch to the tapestry.js
>
> Good luck,
> Joost
>
> On Mon, May 25, 2009 at 7:04 PM, Markus Joschko
> <ma...@gmail.com> wrote:
> > OK I see. I could potentially encode all possible parameters for the
> > draggables and droppables already on the serverside and then append
> > them in javascript to the base URL.
> > That would work in my case. However if the parameters are also dynamic
> > and change in the browser, I'm out of luck with this approach.
> > Seems to me like a clientside encoder is missing. Then it would be
> > possible to generate the baseURL on the server and add whatever the
> > client is coming up with as parameters.
> >
> >
> > On Mon, May 25, 2009 at 6:05 AM, Joost Schouten (mailing lists)
> > <jo...@jsportal.com> wrote:
> >> I believe the URLEncoder can help here if I'm not mistaken, this
> >> obviously limit you to server side generation of the url parameters.
> >>
> >> Just:
> >>
> >> @Inject
> >> private URLEncoder urlEncoder;
> >>
> >> in your methods
> >> urlEncoder.encode("whatever=youwant");
> >>
> >> Haven't tested this and just got it from the api. Should work I guess.
> >>
> >> Good luck,
> >> Joost
> >>
> >>
> >>
> >>
> >>
> >> On Mon, May 25, 2009 at 2:58 AM, Markus Joschko
> >> <ma...@gmail.com> wrote:
> >>> But then you loose the special encoding tapestry does e.g for the =
> sign, or?
> >>>
> >>> On Sun, May 24, 2009 at 12:07 AM, Joost Schouten (mailing lists)
> >>> <jo...@jsportal.com> wrote:
> >>>> I personally prefer generating an eventlink and adding the parameters
> >>>> the normal tapestry way. Then Tapestry will take care of everything
> >>>> for you. So still only generate one Link
> >>>> (pageOrComponentUrl:eventName) and append the parameters server side
> >>>> and pass them using RenderSupport.addScript() or append the params
> >>>> client side.
> >>>>
> >>>> eg: pageOrComponentUrl:eventName/StringVar1/LongVar2
> >>>>
> >>>> on your page:
> >>>>
> >>>> @OnEvent(value = "eventName")
> >>>> private Object handleEvent(String var1, Long var2) {
> >>>>    ...do stuff and return JSON/Block/null/Page class/Link/String
> url...
> >>>> }
> >>>>
> >>>> or if the params can be of many different configurations
> >>>>
> >>>> @OnEvent(value = "eventName")
> >>>> private Object handleEvent(EventContext context) {
> >>>>    ...do stuff and return JSON/Block/null/Page class/Link/String
> url...
> >>>> }
> >>>>
> >>>> Cheers,
> >>>> Joost
> >>>>
> >>>> On Sun, May 24, 2009 at 9:19 AM, Markus Joschko
> >>>> <ma...@gmail.com> wrote:
> >>>>> Thanks, never thought about "normal parameters".
> >>>>> I then probably need to do the coercion&stuff on my own. I guess
> there
> >>>>> is a service I can use for that. However it still feels like hack.
> >>>>>
> >>>>>
> >>>>> On Sat, May 23, 2009 at 10:06 PM, Thiago H. de Paula Figueiredo
> >>>>> <th...@gmail.com> wrote:
> >>>>>> Em Sat, 23 May 2009 16:17:11 -0300, Markus Joschko
> >>>>>> <ma...@gmail.com> escreveu:
> >>>>>>
> >>>>>>> But that does not scale very well.
> >>>>>>> Only 10 draggables and 10 droppables would result into 100
> potential
> >>>>>>> links that I need to render "just in case".
> >>>>>>> And if you have to deal with 100 draggables this gets really ugly.
> >>>>>>
> >>>>>> So generate a single link that will have query parameters on them
> >>>>>> (/page/event?x=1&y=2). ;) To get the parameters, @Inject the Request
> >>>>>> service.
> >>>>>>
> >>>>>> --
> >>>>>> Thiago H. de Paula Figueiredo
> >>>>>> Independent Java consultant, developer, and instructor
> >>>>>> http://www.arsmachina.com.br/thiago
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

Re: Best practices to trigger serverside event methods from javascript?

Posted by Peter Stavrinides <P....@albourne.com>.
> In my case, I did as Howard suggested and captured that scenario in my
> dispatcher, encoded the search
> term into a new url, and did a redirect.
+ 1 

I use this too and it works well.

----- Original Message -----
From: "Brian Deterling" <br...@gmail.com>
To: "Tapestry users" <us...@tapestry.apache.org>
Sent: Tuesday, 23 June, 2009 00:32:55 GMT +02:00 Athens, Beirut, Bucharest, Istanbul
Subject: Re: Best practices to trigger serverside event methods from  javascript?

I have a similar scenario. I want the user to be able to do a search and end
up at a nice url like /search/term. However, if their session times out, I'd
like to capture the original url, wait for them to log back in (or log in
automatically via cookie), and then redirect them to the original url. Since
forms use POST, I can't do that unless I use a non-Tapestry form or use
onclick to build the url but then if they enter a space or other invalid
character in the search term, the url isn't encoded correctly for Tapestry.
Someone posted a client-side encoder in
https://issues.apache.org/jira/browse/TAP5-637 so that's one option.
In
my case, I did as Howard suggested and captured that scenario in my
dispatcher, encoded the search
term into a new url, and did a redirect.

Brian

On Mon, May 25, 2009 at 4:15 AM, Joost Schouten (mailing lists) <
joost_ml@jsportal.com> wrote:

> I believe the encoding is fairly simple and shouldn't be too hard to
> do on the client. if there is a wider need for it, you could consider
> proposing a patch to the tapestry.js
>
> Good luck,
> Joost
>
> On Mon, May 25, 2009 at 7:04 PM, Markus Joschko
> <ma...@gmail.com> wrote:
> > OK I see. I could potentially encode all possible parameters for the
> > draggables and droppables already on the serverside and then append
> > them in javascript to the base URL.
> > That would work in my case. However if the parameters are also dynamic
> > and change in the browser, I'm out of luck with this approach.
> > Seems to me like a clientside encoder is missing. Then it would be
> > possible to generate the baseURL on the server and add whatever the
> > client is coming up with as parameters.
> >
> >
> > On Mon, May 25, 2009 at 6:05 AM, Joost Schouten (mailing lists)
> > <jo...@jsportal.com> wrote:
> >> I believe the URLEncoder can help here if I'm not mistaken, this
> >> obviously limit you to server side generation of the url parameters.
> >>
> >> Just:
> >>
> >> @Inject
> >> private URLEncoder urlEncoder;
> >>
> >> in your methods
> >> urlEncoder.encode("whatever=youwant");
> >>
> >> Haven't tested this and just got it from the api. Should work I guess.
> >>
> >> Good luck,
> >> Joost
> >>
> >>
> >>
> >>
> >>
> >> On Mon, May 25, 2009 at 2:58 AM, Markus Joschko
> >> <ma...@gmail.com> wrote:
> >>> But then you loose the special encoding tapestry does e.g for the =
> sign, or?
> >>>
> >>> On Sun, May 24, 2009 at 12:07 AM, Joost Schouten (mailing lists)
> >>> <jo...@jsportal.com> wrote:
> >>>> I personally prefer generating an eventlink and adding the parameters
> >>>> the normal tapestry way. Then Tapestry will take care of everything
> >>>> for you. So still only generate one Link
> >>>> (pageOrComponentUrl:eventName) and append the parameters server side
> >>>> and pass them using RenderSupport.addScript() or append the params
> >>>> client side.
> >>>>
> >>>> eg: pageOrComponentUrl:eventName/StringVar1/LongVar2
> >>>>
> >>>> on your page:
> >>>>
> >>>> @OnEvent(value = "eventName")
> >>>> private Object handleEvent(String var1, Long var2) {
> >>>>    ...do stuff and return JSON/Block/null/Page class/Link/String
> url...
> >>>> }
> >>>>
> >>>> or if the params can be of many different configurations
> >>>>
> >>>> @OnEvent(value = "eventName")
> >>>> private Object handleEvent(EventContext context) {
> >>>>    ...do stuff and return JSON/Block/null/Page class/Link/String
> url...
> >>>> }
> >>>>
> >>>> Cheers,
> >>>> Joost
> >>>>
> >>>> On Sun, May 24, 2009 at 9:19 AM, Markus Joschko
> >>>> <ma...@gmail.com> wrote:
> >>>>> Thanks, never thought about "normal parameters".
> >>>>> I then probably need to do the coercion&stuff on my own. I guess
> there
> >>>>> is a service I can use for that. However it still feels like hack.
> >>>>>
> >>>>>
> >>>>> On Sat, May 23, 2009 at 10:06 PM, Thiago H. de Paula Figueiredo
> >>>>> <th...@gmail.com> wrote:
> >>>>>> Em Sat, 23 May 2009 16:17:11 -0300, Markus Joschko
> >>>>>> <ma...@gmail.com> escreveu:
> >>>>>>
> >>>>>>> But that does not scale very well.
> >>>>>>> Only 10 draggables and 10 droppables would result into 100
> potential
> >>>>>>> links that I need to render "just in case".
> >>>>>>> And if you have to deal with 100 draggables this gets really ugly.
> >>>>>>
> >>>>>> So generate a single link that will have query parameters on them
> >>>>>> (/page/event?x=1&y=2). ;) To get the parameters, @Inject the Request
> >>>>>> service.
> >>>>>>
> >>>>>> --
> >>>>>> Thiago H. de Paula Figueiredo
> >>>>>> Independent Java consultant, developer, and instructor
> >>>>>> http://www.arsmachina.com.br/thiago
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

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