navigating the peoplesoft component buffer
TRANSCRIPT
8/11/2019 Navigating the PeopleSoft Component Buffer
http://slidepdf.com/reader/full/navigating-the-peoplesoft-component-buffer 1/2
Navigating the PeopleSoft Component BufferKEVIN 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 numberof 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 logicalstructure 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 consideringhow 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 ofRecords) 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 level0 — 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 variousRecords. 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 theRecords 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 (andvariations 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
8/11/2019 Navigating the PeopleSoft Component Buffer
http://slidepdf.com/reader/full/navigating-the-peoplesoft-component-buffer 2/2
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, Irefer 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.