Forum OpenACS Development: FYI: User message feature

Posted by Lars Pind on
Branimir mentioned a usability study he'd seen on OpenACS, where one of the main problems found was the lack of confirmation on your actions. For example, when you've created a new object, you're just thrown back to a page with a long list of objects, where your object is just one of them.

We came up with the solution of showing a message in yellow somewhere along the top of the page saying "Your message "Foobar" has been posted.".

To see what it looks like, visit Collaboraid's developer blog (can't post images here).

We also came up with a simple design for how to implement this, which is simply to store the message server-side and request, then clear it, on the receiving page. There's no DB hit involved.

(I'm not sure whether it works on clusters. So long as the load-balancer makes you go to the same web server each time, we should be fine. The worst that can happen is that you don't get the confirmation, which is what we have today.)

In practice, you say this:

ad_returnredirect -message "Your message \"$title\" has ben posted." $return_url
The display is automatically handled by the site-master template, so you don't need to do anything else at all.

(While we were at it, I also added a -abort switch to ad_returnredirect, so you don't have to call ad_script_abort.)

Also, you can put multiple messages using util_user_message, and you can also use HTML in your message if you set the -html flag.

Let me know if this is a useful feature, or you want it removed before the release.

Posted by Barry Books on
I had a similar problem and I run a clustered site. I just added new_object_id=XXX to the redirect url. That way no matter where you end up you can display a message about the new object. I guess you could put the message into the url.
Posted by Samer Abukhait on
This is really cool

Regarding the -abort, I have this question:

Is it really needed to call ad_returnredirect without aborting?
Why the aborting is not the default behavior in ad_returnredirect.

I am using:
ad_proc redirect {target_url} {
  A synonym to ad_returnredirect.
} {
        ad_returnredirect $target_url

Posted by Tilmann Singer on
Cool feature - (why would anyone want that to be removed?)!

I don't know about problems with clustered sites, but putting the message in the url has a few drawbacks. For example that the message will be displayed again when doing a reload of the page, or when mailing/bookmarking the url.

Samer, this is a 'don't break existing code' issue. Adding a new proc that redirects and aborts is fine, but changing the default behaviour of ad_returnredirect now would break existing code that relys on that behaviour. I think the -abort switch is a nice compromise - this way we don't even have to remember a new proc name.

Posted by Lars Pind on
One drawback of adding switches to ad_returnredirect: If you redirect to a URL that happens to start with a hyphen, it will break, unless you put "--" in front of it.

Is that something we need to be concerned with?


Posted by Andrew Piskorski on
Offhand, I doubt that URLs starting with "-" occur anywhere in OpenACS in practice.

But this is a good example of one of Tcl's minor but annoying warts. I tend to habitually use "--" everywhere I think it might work, until "Oops, got an error, oh yeah, this particular Tcl command doesn't accept the '--' option, take it out."

And once you define a proc with no option switches at all, it seems that for 100% backwards compatibility you must never add any switches ever. Actually, hm, I suppose you could kludge something into ad_returnredirect to check the number of arguments it received, and implicitly add the "--" if necessary. That means doing its own parsing rather than using ad_proc though, which is probably both not worth it and a bad idea. Instead, perhaps it would be worthwhile to extend ad_proc itself to optionally support some such feature?

Posted by Andrew Piskorski on
On the real issue of confirmation at the top of the page, yes, good work, OpenACS definitely should have that! :) Lars' description of how to implement that sounds like the right thing to me. Of course, in that design, the code displaying the "your foo has been saved" message never actually checks that the foo was in fact saved correctly, it just believes what the referring told it. But that should be fine, especially since it seems like a good idea to avoid an extra DB hit there.

On the minor question of adding some sort of "-abort" switch to ad_returnredirect, no, IMNSHO, I don't think that's such a good idea. This is a minor and not at all particularly important issue, but I figured I might as well present my reasoning:

There are perfectly good reasons to do a redirect without stopping further execution of the Tcl script (we all know that). Currently, ad_returnredirect is a nice simple proc that does exactly one thing (this is good). And I don't see how any advantage to the developer in adding an "-abort_script_p 1" "-abort" or whatever switch to his ad_returnredirect call rather than adding a "ad_script_abort" line immediately after ad_returnredirect. Adding the switch isn't any savings in typing nor easier to remember, so I don't see any advantage at all to the extra tiny little bit of complexity. Adding such a switch to ad_returnredirect looks like pointless and fattening syntactic sugar to me.