Announcing Events & url variables

[jeff]

I've googled high and low and I really thought i would have found this
by now but i didn't so its mailing list time:

I have an event where the user clears an "alert" and then after we're
done, we want to bounce them back to the page that shows all alerts.

Here is my XML code:

<event-handler event="alert.all" access="public">
<filter name="checkPermissions"/>
<notify listener="AlertListener" method="listAlerts"
resultArg="alerts" />
<view-page name="AdminAllAlerts" />
</event-handler>

<event-handler event="alert.clear" access="public">
<notify listener="AlertListener" method="clearAlert"
resultArg="alerts" />
<announce event="alert.all"/>
</event-handler>

So, basically, i call event=alert.clear. Then after its done, it
calls event=alert.all to show me all the alerts. HOWEVER, the url
variables at the top of the page still show for alert.clear. I really
want to FORWARD the user to alert.all, not throw it on top of
alert.clear, which i think is what I am doing.

Is there a proper way to take care of this? Bonus points if you tell
me how to do it inside of a filter (i need to know that too)

[Jennifer Larkin]

I don't understand why the url variables are a problem. It doesn't matter what event displays to the user in the URL as long as the page displays correctly.

--
I did not come here to get devoured by symbols of monarchy! -- Smirnov of the KGB, Casino Royale

Now blogging....
http://www.blivit.org/blog/index.cfm
http://www.blivit.org/mr_urc/index.cfm

[Matt Williams]

If you wish to have the url change, use <redirect event="alert.all" />
instead of <announce>.

--
Matt Williams
"It's the question that drives us."

[jeff]

For 95% of the time you are correct, but if they decide to bookmark
that particular page, or try to send the URL to a friend for some
reason, it may not have the desired effect.

[Peter J. Farrell]

The other problem is if somebody did a post to that event.  If they hit refresh, the browser will ask if it can repost -- causing duplicates.  Better to redirect -- however, I think the <redirect> command was in a version later than the one you are all using.

.pjf

jeff said the following on 6/12/2008 12:04 PM:

[Jennifer Larkin]

The page in question is an alerts queue. The only submit on the page is to clear an alert. If the variables for clearing a cleared alert exist, we can rerun the clear alert function with no bad side effects. If someone gets to the page through a bookmark, then those variables don't exist. Since we shouldn't be running the clear alert function without an alertid to clear regardless of how the user got to the page, we need to handle that case regardless of bookmarks and in the case, the proper way to handle it is to abort the function that clears the alert and continue with page flow, which is to list the alerts. I'm not saying that this wouldn't be useful on other pages but on this specific page, the expected behavior should be:
is there an alertid to clear?

[Jennifer Larkin]

Argh! killed by the tab button! See below.

On Thu, Jun 12, 2008 at 11:12 AM, Jennifer Larkin <jla...@gmail.com> wrote:

The page in question is an alerts queue. The only submit on the page is to clear an alert. If the variables for clearing a cleared alert exist, we can rerun the clear alert function with no bad side effects. If someone gets to the page through a bookmark, then those variables don't exist. Since we shouldn't be running the clear alert function without an alertid to clear regardless of how the user got to the page, we need to handle that case regardless of bookmarks and in the case, the proper way to handle it is to abort the function that clears the alert and continue with page flow, which is to list the alerts. I'm not saying that this wouldn't be useful on other pages but on this specific page, the expected behavior should be:
is there an alertid to clear?

If so, mark the alert cleared. (If it's cleared, this causes no change.)
If not, oh well.
Continue with page processing.

I don't want us to get into the habit of redirecting the user on every request when the request can continue as expected if we merely rely on rules that we have to put in regardless of how the user got to the page.