SRP Editor – Service Modules & Metadata

As alluded to in our pre-Christmas release of version 2.7 of the SRP Editor, I drew attention to a new (well, partially new) feature referred to as metadata. Of course, the term metadata is well known, especially to those who work with information technology. Simply put, metadata means “data about data”. OpenInsight developers use metadata all the time in the form of Data Dictionaries.

So how does the SRP Editor support metadata? What kind of data would the SRP Editor be describing? Even better, how will this benefit you as a user of the SRP Editor? Great questions. Let’s spend some time exploring the answers.

To set the groundwork let’s discuss the concept of service modules. In the parlance of the SRP Editor, service modules are stored procedures (usually functions), that accept generic arguments, provide one or more unique processes (often via GoSub calls) based on the argument values. Each of these self-contained processes typically have a broad relationship with one another, which explains why they are placed within the same stored procedure. Again, nothing ground breaking here. R/BASIC developers have been writing code like this since the good ole’ DOS days of AREV. We usually refer to these as Commuter Modules. This tradition has been so well ingrained into our minds, that it transferred into OpenInsight and has been formally embraced by the Form Designer and by Revelation Software’s own Editor ++.

OpenInsight has a number of routines that work this way, such as Repository, Utility, and Rev_Utility. (There are other functions, like Set_Property and Set_Printer, which have similar characteristics, but we will not include them in this discussion just yet.) As already mentioned, SRP refers to these types of functions as service modules, but you can call them anything you wish (e.g., commuters, helper routines, or process routers). Building applications around service modules has become a fundamental part of our framework methodology, providing a method for organizing our business logic and making it easier to extend our services through various APIs. This was a given special attention in Kevin Fournier’s SOA presentation at the 2010 Revelation User’s Conference.

As useful as they are, there has always been one area where service modules have become somewhat counter-productive: call tips. For most stored procedures, call tips are quite handy as demonstrated below:

Yet, for stored procedures styled after the service module format, call tips are less helpful:

The very feature that makes service modules what they are – generic arguments – is the very feature that makes call tips less than useful. This is what gave birth to SRP Editor’s support for metadata.

By using metadata, the SRP Editor can now provide the developer two useful features. The first benefit comes through some enhanced code complete, where by developers are provided a list of options when these are known. Going back to the above example of the Rev_Utility function, we know all possible options for the method argument because these are documented. Therefore, by creating metadata for Rev_Utility, the SRP Editor can now provide the developer with this list automatically:

Note, however, that the call tip still only shows generic arguments. This is because the SRP Editor does not know any better. It must rely on the arguments as extracted directly from Rev_Utility. This changes the moment a specific method is selected…which brings us to the second benefit of metadata. Once an argument is populated, the call tips automatically adjust as needed:

Earlier we made a brief reference to non-service module functions like Set_Property and Set_Printer. Well, even though they are not strictly service modules, they do provide arguments with known values. Consequently, the SRP Editor can employ metadata to support these functions as well:

Alas, the SRP Editor does need to be configured to enable support for metadata. This is done through Tools > Options > Autocomplete. The setting of Enabled – Including Keywords will enable metadata support. Now, we know that some of you prefer to disable the Autocomplete feature, which we understand. Fortunately, we have provided support for just metadata, as you can see below:

The SRP Editor ships with metadata already prepared for Set_Property. We’ll add more SSP metadata in the next release. In a near future article we will also demonstrate how you can add your own metadata, either for system stored procedures (SSPs) or for your own code. For now, we hope you can start seeing how beneficial this can be to your programming experience.