You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Adrian Crum <ad...@hlmksw.com> on 2008/02/08 16:42:24 UTC
Question about request events
I'm working on some screen widget enhancements that will make use of the new user preferences
services. There is a setUserPreference request event defined in common-controller.xml that is set up
to return the user to the "main" view.
I need the ability to call this request event (or a similar one) and return back to the same view,
or URL. Can that be done, and if so, how?
-Adrian
Re: Question about request events
Posted by BJ Freeman <bj...@free-man.net>.
I know from a user view that you can return to previous pages.
it would seem to me that just a construct of component/controller/main
would accomplish this on a page.
Adrian Crum sent the following on 2/8/2008 7:42 AM:
> I'm working on some screen widget enhancements that will make use of the
> new user preferences services. There is a setUserPreference request
> event defined in common-controller.xml that is set up to return the user
> to the "main" view.
>
> I need the ability to call this request event (or a similar one) and
> return back to the same view, or URL. Can that be done, and if so, how?
>
> -Adrian
>
>
>
Re: Question about request events
Posted by David E Jones <jo...@hotwaxmedia.com>.
That's a little easier actually. It's just like the add to cart and
stay on same page stuff. Just make your urls like this:
/Webapp/control/request-uri/view-name
-David
On Fri, 08 Feb 2008 12:06:31 -0800
Adrian Crum <ad...@hlmksw.com> wrote:
> I was thinking if I just had the event property and no response
> properties, then the controller would just go back to the original
> url, but I didn't try it. Based on your reply, I guess that doesn't
> work.
>
> It would be nice to have that capability.
>
> Let's say I want to have a collapsible masthead. There would be a
> link in the top right corner that looks like the +/- sign, and
> clicking on it calls the setUserPreference request event and returns
> back to the original screen - with the masthead updated accordingly.
> So, what you're saying is right now each screen would have to have
> its own controller entry for the setUserPreference request event.
>
> -Adrian
>
> David E Jones wrote:
>
> >
> > The only way to do this sort of thing right now is to define
> > another request to use instead of the setUserPreference request,
> > but that uses the same event as that request. That way you can use
> > the proper response and route as needed/desired.
> >
> > In thinking about this there are a couple of framework enhancements
> > we could consider to make this easier:
> >
> > 1. some sort of response type that calls the other response, then
> > comes back with the result from any event on that response and
> > uses that result to choose another response
> >
> > 2. some sort of response type that when used goes to the previous
> > request; it would always have a default request to go to, but
> > would only use that if the request it is a response to was called
> > directly instead of as a response to another request-map
> >
> > -David
> >
> >
> > On Feb 8, 2008, at 8:42 AM, Adrian Crum wrote:
> >
> >> I'm working on some screen widget enhancements that will make use
> >> of the new user preferences services. There is a
> >> setUserPreference request event defined in common-controller.xml
> >> that is set up to return the user to the "main" view.
> >>
> >> I need the ability to call this request event (or a similar one)
> >> and return back to the same view, or URL. Can that be done, and if
> >> so, how?
> >>
> >> -Adrian
> >
> >
> >
Re: Question about request events
Posted by Adrian Crum <ad...@hlmksw.com>.
I was thinking if I just had the event property and no response properties, then the controller
would just go back to the original url, but I didn't try it. Based on your reply, I guess that
doesn't work.
It would be nice to have that capability.
Let's say I want to have a collapsible masthead. There would be a link in the top right corner that
looks like the +/- sign, and clicking on it calls the setUserPreference request event and returns
back to the original screen - with the masthead updated accordingly. So, what you're saying is right
now each screen would have to have its own controller entry for the setUserPreference request event.
-Adrian
David E Jones wrote:
>
> The only way to do this sort of thing right now is to define another
> request to use instead of the setUserPreference request, but that uses
> the same event as that request. That way you can use the proper
> response and route as needed/desired.
>
> In thinking about this there are a couple of framework enhancements we
> could consider to make this easier:
>
> 1. some sort of response type that calls the other response, then comes
> back with the result from any event on that response and uses that
> result to choose another response
>
> 2. some sort of response type that when used goes to the previous
> request; it would always have a default request to go to, but would
> only use that if the request it is a response to was called directly
> instead of as a response to another request-map
>
> -David
>
>
> On Feb 8, 2008, at 8:42 AM, Adrian Crum wrote:
>
>> I'm working on some screen widget enhancements that will make use of
>> the new user preferences services. There is a setUserPreference
>> request event defined in common-controller.xml that is set up to
>> return the user to the "main" view.
>>
>> I need the ability to call this request event (or a similar one) and
>> return back to the same view, or URL. Can that be done, and if so, how?
>>
>> -Adrian
>
>
>
Re: Question about request events
Posted by David E Jones <jo...@hotwaxmedia.com>.
The only way to do this sort of thing right now is to define another
request to use instead of the setUserPreference request, but that uses
the same event as that request. That way you can use the proper
response and route as needed/desired.
In thinking about this there are a couple of framework enhancements we
could consider to make this easier:
1. some sort of response type that calls the other response, then
comes back with the result from any event on that response and uses
that result to choose another response
2. some sort of response type that when used goes to the previous
request; it would always have a default request to go to, but would
only use that if the request it is a response to was called directly
instead of as a response to another request-map
-David
On Feb 8, 2008, at 8:42 AM, Adrian Crum wrote:
> I'm working on some screen widget enhancements that will make use of
> the new user preferences services. There is a setUserPreference
> request event defined in common-controller.xml that is set up to
> return the user to the "main" view.
>
> I need the ability to call this request event (or a similar one) and
> return back to the same view, or URL. Can that be done, and if so,
> how?
>
> -Adrian