When editing files via the web in Zope, pressing the Change button gives you a dialog saying "Your changes have been saved", after which you get to click Okay to continue working. If you work by editing/saving/reloading the same page iteratively, this can get tedious. This patch creates a AutoMessageDialog object. It functions just like the tradional MessageDialog, but it *times out* after a couple seconds, sending the user to the next page. The AutoMessageDialog is installed in the edit-document page, but no others, and the timeout is defaulted to 2 seconds. Lemme know if this is useful. http://people.magnet.com/~johnm/Zope/autodialog.patch - j
John Mitchell wrote:
When editing files via the web in Zope, pressing the Change button gives you a dialog saying "Your changes have been saved", after which you get to click Okay to continue working. If you work by editing/saving/reloading the same page iteratively, this can get tedious.
I agree very much.
This patch creates a AutoMessageDialog object. It functions just like the tradional MessageDialog, but it *times out* after a couple seconds, sending the user to the next page. The AutoMessageDialog is installed in the edit-document page, but no others, and the timeout is defaulted to 2 seconds.
Lemme know if this is useful.
This sound's cool. Some other ideas to kick around: - Some additional change buttons: "Change and View" - saves changes and shows results. This should work nicely with the browsers back button I think. "Change and Edit" - Returns immediately to the edit screen wo dialog. "Change and Done" - Saves and displays folder contents. - A status area that gives some feedback on the previous action. The rule that we've followed is that we don't have to show the message dialog if the screen is different after an operation. This is why there's no dialog when adding and deleting items in a folder. A status line could be blank normally and show something like: "Changes saved at <time>" after a change. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
On Wed, 13 Jan 1999, Jim Fulton wrote:
Some other ideas to kick around:
- Some additional change buttons:
"Change and View" - saves changes and shows results. This should work nicely with the browsers back button I think.
"Change and Edit" - Returns immediately to the edit screen wo dialog.
"Change and Done" - Saves and displays folder contents.
Hmm. I believe the best way to accomplish this functionality is to *ignore* it! That is, *dont* add more buttons onto each editable screen. If you want a view, then have a 2nd browser open to reload it. Else things get hairy way too fast... Others: comments?
- A status area that gives some feedback on the previous action. The rule that we've followed is that we don't have to show the message dialog if the screen is different after an operation. This is why there's no dialog when adding and deleting items in a folder.
A status line could be blank normally and show something like: "Changes saved at <time>" after a change.
Jim
A policy I've used successfully is to have virtually all apps be one-pagers. That is, the "Fill out Form" and "Oops: please type zipcode again" pages are *the same*; except for a bit of code in the header that says "if there was a status message, show it; otherwise continue." For example, check out this app: http://www.mayohealth.org/cgi-bin/apps/list_mailer2?list=alzupdate Hit the form, type "haha" in the Name form, then press Subscribe. You'll get the same page back with a warning in the top part of the page. All fields remain filled-in, so you the user can just edit his information and continue. Another take: Netscape's Calendar product allows you to create tasks, meeting arrangements, etc. The web version uses a two-step procedure to show you that it accepts what you told it. Click "Create", it shows a small-font, one-line message: "Your note has been successfully created", then sends you to your main Calendar page again. This is more resource-intensive, but for intranet-type apps like this one it's very effective. - j
Hi John (John Mitchell), in <Pine.SGI.4.05.9901131634130.21231-100000@lemur.magnet.com> on Jan 13 you wrote:
A policy I've used successfully is to have virtually all apps be one-pagers. That is, the "Fill out Form" and "Oops: please type zipcode again" pages are *the same*; except for a bit of code in the header that says "if there was a status message, show it; otherwise continue."
For example, check out this app: http://www.mayohealth.org/cgi-bin/apps/list_mailer2?list=alzupdate
Hit the form, type "haha" in the Name form, then press Subscribe. You'll get the same page back with a warning in the top part of the page. All fields remain filled-in, so you the user can just edit his information and continue.
We do this quite a bit also, however one should note that care must be taken with browser cacheing issues here. POSTs, in particular, can get quite interesting, especially with Netscape and I.E. Kent
participants (3)
-
Jim Fulton -
John Mitchell -
kent＠eaenki.nde.swri.edu