HTML Areas and Server Communication | KEVIN RESCHENBERG 05-05-2014 |
These last few posts have been about using HTML areas to modify the appearance and behavior of pages, or to get around limitations in the
HTML generated by PeopleTools. PeopleSoft is very good at handling input and display of multi-level data on pages. But sometimes you
might want to take control and pass data back and forth from the server (i.e., your PeopleCode).
For example, one of my pages must display a grid containing as many as 15,000 cells, some of which are input fields. This is controlled
dynamically—the types of data to be displayed and the order of the columns are known only at runtime. This
is not something that lends itself to a regular PeopleSoft grid. So I implemented it by building my own scrollable HTML table in an HTML area.
(Building a huge string like this through concatenation presents a completely unrelated performance issue, which I'll discuss in the next post.)
OK, that's easy enough, but what about the input fields? PeopleSoft doesn't know about them since they are just regular HTML inputs. I needed to use
JavaScript to copy the data back and forth between these input fields and "real" PeopleSoft input fields, which are hidden off to the side.
Another example: Recently I created a page that lets the user paste from the clipboard into a long character field and then post it back to the server
for processing. To keep it very simple for the user, I
wanted the entire process to be implemented by a single button without a visible long character textbox. The button click handler fills the hidden field
with the clipboard's contents and submits the page.
Both of these cases called for invisible "real" fields on the page. PeopleTools would know about these fields but they would be invisible to the user.
There is just one problem: If we make these "real" fields invisible using the field properties dialog, or in PeopleCode using .Visible = False ,
they won't work. PeopleTools knows that these fields are not intended to be filled by the user, so it doesn't generate an actual textbox or anything else.
The solution is to tell PeopleTools that these are regular visible fields, and then hide them later. One simple way is to put them inside a groupbox.
This groupbox will become a DIV that includes the fields. Then we can use an HTML area
to make this groupbox (and its contents) invisible. This can be done with JavaScript if the groupbox has a name (record.field specification in the groupbox's properties).
Or, more simply, we can use CSS. Give the groupbox a body style of, say, RESET.
Remove the title text so that the groupbox won't show a title. Set the border to hidden. Then add an HTML area to the page:
<style type="text/css">
.RESET {display: none;}
</style>
Now as far as the browser is concerned, the input fields within this groupbox still exist and can be read or changed, but the user cannot see them.
You can use these fields to communicate data back and forth as needed. The same technique can be used with buttons that you .click() with JavaScript.
|