| Navigating the PeopleSoft Component Buffer | KEVIN RESCHENBERG
12-20-2006 |
PeopleCode is an interesting language. It's event-driven, procedural, and
object-oriented, depending on how you look at it or use it. It's designed
specifically around the main problem of managing hierarchical data on screen pages.
That doesn't sound very difficult at first glance, but we're really dealing
with up to four levels in a hierarchy, with each level containing any number of fields from
any number of records (tables, views, and/or make-believe derived "tables"), and
multiple rows at each level, spread across multiple pages that must act
as if they are aware of each others' data even though, at the page level,
they aren't. And the hierarchy isn't just a set of levels of related data—it's
actually a tree, with different branches related only through their parents.
And after the designers solved that problem, they created an
entire programming language that includes a lot of functionality. And it works.
Not bad.
But digging through the component buffer can be confusing. The buffer, of course,
is the logical structure that stores all of the data for a component. Although
we generally focus on page design and the data displayed by pages, a page is
a relatively unimportant concept when considering how the data is managed. It's
better to think of the component as one very large page, and each page object
is just a section of it. Pages are there mostly for the convenience of the
user. It's better to organize information under multiple tabs than to display
everything all at once.
While learning PeopleCode (and do we ever stop learning it?), I was pretty confused
about navigating the buffer. One problem was with the terminology: Record, Rowset,
Scroll Area, Row, and so on. "Record" refers to a table, view, or derived, um, record.
A Record is not a Row. In the buffer, a Row contains Records, even though physical tables
and views (examples of Records)
contain rows. OK, I realize I'm making it worse so let's just start over.
A Rowset pretty much corresponds with a scroll area that appears on a page. Each
Rowset is an entire tree in itself, but ignore that and think of it as the data in a scroll area.
The Rowset at level 0—the top of the hierarchy—contains one Row. Other
Rowsets can contain multiple Rows.
Each Row consists of many Fields and/or child Rowsets. These fields can come from various Records. There
is a primary Record, which gives the Rowset (containing this Row) its name. There can also be other Records—for
example, related display records. Rowset, Row, Record, Field. Fields are on Records.
The data from these fields make up a Row, where one of the Records is marked as the
primary one. Rows are identified by number, starting at 1. The Rows make up the Rowset.
The Rowset takes its name from the main Record mentioned above. Rowsets are identified
by name and/or level, depending on context.
Another complication is that there are two different ways of coding the navigation (and
variations within those ways, but never mind). There is the version 8.x "object oriented"
way, and the previous way which just uses names instead of obtaining and manipulating
object references. The old way is still supported. And then there are the "RECORD."
syntax and the "scrollpath" syntax, but never mind.
Also, since each PeopleCode program exists within a particular context (a Field on
a Record on a particular Row, for example), it has a local area of objects that it
can deal with directly. For example, a program located on JOB.EMPL_STATUS can look
at that one field's value, even though that might be one field on one row at level 2
in the buffer. If you refer to something else without specifying a complete path to
it, the Component Processor will start travelling up the tree (toward level 0) until
it finds something that matches.
Someone gave me an example that has helped me deal with all of this, and I've been
carrying it around with me for several years. Unfortunately
I don't know where it came from. It's just a one-line "shortcut" example of navigating
to a particular piece of data. Whenever I get confused, I refer to this example and it
somehow helps me focus. This assumes all row numbers are 1, but those 1s can of course
be replaced with variables.
&F = GetLevel0()(1).EMPL_CHECKLIST(1).EMPL_CHKLST_ITM(1).EMPL_CHKLST_ITM.BRIEFING_STATUS;
Rowset Row Rowset Row Rowset Row Record Field
This is a shortcut because it navigates all the way
down in one line of code, instead of obtaining a reference to each object
in turn. Which way you do it depends on your particular circumstances.
|
