| A Cancel Button | KEVIN RESCHENBERG
11-28-2007 |
I've been working for some time on developing self service functionality
for a client. This involves both new pages and rewrites of delivered
pages. I wanted to put both Save and Cancel buttons on a page. The
Save functionality is easy in this case. For Cancel, I wanted the button
to return to our custom menu (just a regular page, not an actual
PeopleSoft menu) and avoid the "you have unsaved data on this page"
message box. That would seem to be a very simple thing to do, but in
practice I found it to be an interesting problem.
Most pages don't need a Cancel button. The user can simply click over
on the side menu and deal with the warning. But self service pages
are intended to be used by people who may never have used PeopleSoft
pages for any other purpose. We have even hidden the side menu
completely for most users so that there is no indication that the rest of the system
even exists. Since there is no regular menu, the only way for a user to
return to our "menu" page is through a button or link.
One solution might be to trick the JavaScript that triggers the
"unsaved data" warning in the first place, but that would be a little
aggressive for our purposes! Another possibility was available to me,
but only because everything in the component is handled with derived
fields and "dummy" views. I decided to go through the Save component
process for both the Save and Cancel buttons.
Each button triggers FieldChange PeopleCode. A component-level boolean
variable is set to indicate that we want to save (in the case of the
Save button) or that we don't want to save (in the case of the Cancel
button). The code then calls SetComponentChanged() so that DoSave()
will work. Finally, DoSave() is called.
In SavePostChange the database is updated as appropriate only if the
component boolean variable indicates that the Save button was clicked.
In either case a Transfer() is done to return to the "menu" page
(or a confirmation page).
This works well. But why would the page consist of only derived
fields and "dummy" views? The more I work on this self service project,
the more I've been drifting away from the "normal" way of doing things
(i.e., relying on search records and the default component processing).
Instead, I've been using a lot of code to populate scroll areas and
grids explicitly, using the No Auto Select switch. In many cases this seems to simplify
the views that are needed and permits extra flexibility. Again, this
would apply mainly to self service pages rather than pages intended
to be used by administrative groups such as Human Resources.
|
