The Object Table View is very powerful, both as a standalone view and as part of the PDM perspective.

In my last article, I introduced you to the Object Table View. This is a relatively recent addition to Rational Developer for i (RDi) and was added in response to those of us who found that the Remote System Explorer (or RSE) perspective was a little too alien. The Remote System Explorer looks at the entire storage of an IBM i as a single hierarchical file system. And while that's technically true, it's just not the way many people think of it, especially traditional green-screen developers. But before we move on to the Object Table View, I'd like to present a feature of RDi called a filter, which can be used in both the Remote Systems and Object Table Views.

QSYS vs. the World

The IBM midrange environment I grew up with was simple: it had libraries, and those libraries had objects. And when we got really complicated, some of those objects were files and the files had members, and that's as deep as it went. In truth, little has changed in what we call the QSYS library system. In fact, if you ignore the IFS, it's exactly the same.

Of course, you can't ignore the IFS, and those of us who fell into the dark realm of Java and QShell and WebSphere learned how to navigate those waters as well. IBM did a fantastic job of melding those two; in my opinion, the idea to essentially treat the entire traditional QSYS library system as just a folder in the IFS was genius. It has allowed green-screen developers to consider the system as having two independent identities: the QSYS side and the IFS side. Or to be honest, it allowed us to all but ignore the IFS completely.

But while programmers can ignore the dual nature of the system, IDEs such as RDi don't have that luxury, especially the part of the tool that allows you to navigate the server. It comes down to the interface; the only comprehensive way to show a nested folder structure is with a tree. Therefore, any part of RDi that was going to allow access to the IFS had to be designed with a tree as its primary structure. As I showed in the previous article, while a tree structure works very well for the IFS, it's not particularly efficient for the QSYS environment. In some ways, it's like a slow version of PDM, especially over a VPN.

Making the Best of the Hierarchy

Out of the box, the hierarchical structure just doesn't stack up to PDM very well for a simple reason: the APIs that underpin PDM are very quick at getting the first members of a list, whether it's libraries (for WRKLIBPDM) or members (for WRKMBRPDM). When you use option 12 to drill into something in the PDM commands, you see the first page of the detail list almost immediately. RDi, on the other hand, does things differently. Whenever you expand something in the hierarchy, RDi goes out and gets all the children, and in large cases that can take some time. You can see the same effect in PDM, though. First, open a particularly large source file, one with hundreds or thousands of source members. Then use F17 to filter based on text.

Figure 1: Using F17 to filter members can take a while.

Even on a faster machine, this can take a while, because PDM has to resolve every member, get its text and compare against the filter. RDi has to go through something like this every time you expand an entry in the list. Now, one way to get around that is to user filters, and while I don't want to spend a lot of time on the Remote Systems View, the concept of a filter is one that actually crosses over from Remote Systems View to Object Table View as we'll see.

What's in a Filter?

A filter is a way to subset the objects in a tree view. It allows you to select a set of like items, whether they're libraries, objects, or members, and access them as if they all resided in a single folder. Here's a very simple example.

Figure 2: Use Work with objects… to create a filter for all the source files in library PBDCSPDEV.

Figure 2 is actually a little bit of a mashup; it shows both how to create a filter and also the results of that filter once it has been created. You create a filter by selecting one of the "Work with" options, either at the library, object, or member level. In this case, I want to see objects, specifically the source files in a library. I start by expanding the Work with objects… option and then filling in the values. Using PF-SRC in the Object attribute field is a pro tip; it will select only those objects with the PF-SRC attribute, which by definition is only source files. This way, you don't have to worry about naming conventions or anything else.

After you create the filter, it will show up in your Objects list. I expanded it in Figure 2, and you can see that it lists all the source files in my PBDCSPDEV library. Using the standard “Work with” technique allows you to create a basic filter, which you can then expand by editing it.

Figure 3: The Properties panel for a filter allows you to edit and add more entries, such as different libraries.

As I noted, I'm not going to spend a lot of time explaining RDi filters; that's a topic that can take up an entire article by itself. But note that my initial filter shows up as one entry in the Filter string list. You might think that implies you can enter more such filter strings, and you would be correct. So you can add sets of source files from different libraries all into a single object list. This by itself is pretty powerful, but I do still have to drill into each file individually in order to get to the underlying members. What would be nice would be a way to see them all at once; not even WRKMBRPDM does that! Enter the Object Table View!

Showing a Filter in the Object Table View

You can easily get to the Object Table View using the context menu for a filter.

Figure 4: Right-click on a filter and select Show in Table to bring up the Object Table View.

This brings up the view as shown in Figure 5.

Figure 5: This is the Object Table View, showing the six source files selected by the PBDCSPDEV Source filter.

The Object Table View is very PDM-like. You can now double-click on one of the entries to drill into it. For example, in Figure 5 I'm double-clicking on QDDSSRC, which brings up the following display.

Figure 6: The window changes to a Member mode view of the QDSSSRC file in PBDCSPDEV.

And in Figure 6 I double-click into the display file source CSPPARMD. This opens the member up in the Screen Designer.

Figure 7: Simple double-click drilling brings me to the Screen Designer.

This is okay, but now, in order to see the related program, I'm going to have to go back up a level, open up my RPG source file, and then open the associated program source member. It's no different than PDM, really. In fact, you can actually type in options 12 and 2 to drill into a source file and edit a member, respectively. This is also an artifact of the old-school method of segregating source members into source files by member type. And while I don't do that myself on new development, it's still a fact of life at many shops. It would be really nice to see all the members for all the selected files in one list. (Is that enough foreshadowing?)

Let's return to Figure 5 and then, rather than drill in to QDDSSRC, let's change the view.

Figure 8: Click the Mode dropdown and change it to Member.

Figure 9: The resulting view lists members in all the selected files.

Now you can see all the members in all the files. My only complaint is that the columns as shown don't give you much detail: specifically, they don't tell you which source file contains the member. That can be fixed; by going into the preferences for the panel, you can configure the columns. That's another topic for another day, but I customized mine and it looks like this:

Figure 10: Here's the Object Table View configured to show members from multiple files.

This is how I like to see members, but that's because I usually don't show members from files in different libraries. If I did, I'd also add a Library column. The attribute column isn't strictly necessary either, although it helps when you accidentally include database members in addition to source members. They show up as DTA rather than SRC.

Keeping It in Perspective

That's the title of this, isn't it? So let me leave you with one more way that the RDi developers have tried to make us old school green-screen developers feel comfortable. This is the PDM perspective.

Figure 11: Use the Open Perspective dialog to open the PDM Perspective.

Figure 12: This is what the PDM Perspective looks like.

Many green-screen programmers prefer this perspective because it's very clean. You have an editing panel along with the outline, and a PDM panel on the bottom. You can drill into and out of your PDM panel, you can easily jump to other files, and because the Objects Table View works with filters, you can create project-specific filters (or whatever sort of organization best fits your development style). Additionally, the uncluttered layout tends to work reasonably well even on smaller screens, such as laptops. Since a lot of us have been using laptops at home as our primary development machines, it's nice to have this sort of fallback.

Personally, I spend too much time in the IFS to make use of the PDM perspective; my customized versions of both editing and debugging perspectives work very well for my development cycle. But I still recommend you kick the tires on this particular perspective, just to see if it fits for you.