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
