navigating the peoplesoft component buffer

2
 Navigating the PeopleSoft C omponent 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 ver y difficult at first glance, but we're really dealing with up to four levels in a hierarchy, with each level c ontaining 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 onl y 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 b uffer, of course, is the logical structure that stores all of the data for a component. Although we generally focus on page d esign 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 con fused 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 R ecords, 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. Ro ws 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

Upload: peterlasking

Post on 02-Jun-2018

212 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Navigating the PeopleSoft Component Buffer

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

Page 2: Navigating the PeopleSoft Component Buffer

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.