The LINCKS GPD
In Linux Journal Issue 11, we described a typical installation of LINCKS, described the functionality of its components, and briefly introduced the main application interface, xlincks. Since LINCKS is distributed with an online tutorial, and a 70-page xlincks manual, we will assume that you know the basics about operating xlincks. In this second and last part, we describe how to create your own views, or general presentation descriptors (GPD), as we call them. For a reference manual description of GPDs, see chapter 7 of the xlincks User's Manual, and for a technical overview description see Journal of Systems and Software.
As a running example, we will show you how to use xlincks to create an address book, and the GPDs used to enter and display data. We start out by designing our data structures, then describe the LINCKS object model, and finally show how the address book is represented in the object model. We briefly describe the automatic search for GPDs used in xlincks and show our first GPD, followed by a description of the GPD's parts. We conclude by extending the newly-created GPDs to demonstrate a few additional features.
In our address book, the two obvious objects are the person object containing personal information, such as: name, birth date, e-mail address, and private phone number, and the address object. An address object can be shared by different persons and contains the common street address and common phone number.
In LINCKS, each object consists of the following parts:
IMAGE storing any type of information which can be PostScript, object code, a GIF, or a name (string). The size must be less than 232-1 bytes and the content is single-valued. (Currently, xlincks can only handle IMAGEs containing zero-terminated strings.)
ATTRIBUTE describing or typing the object. The value of an attribute is a zero-terminated string shorter than 216-1 bytes. An attribute is named by two strings, a group tag and a field tag, where several attributes can share the same group tag, but the combination of group and field must be unique.
LINKS containing links to other objects. A link field is plural, that is, for each object it can contain several links to other objects, as opposed to the attributes, which are single-valued.
In Figure 1, the window with three entries is the person object where the image contains the person's name, the second line specifies the birth date, and the fourth line is a link to an address object. The second, bigger window is the node view applied to the same object. (To apply another view, click on the item, then on the “Expand...” menu item, and then choose the node view. See the previous article in Issue 11, or read the xlincks manual, for more information.) The first entry in the node view is the image, followed by all the attributes and finally the link section beginning with the SYSTEM:Parent entry.
Notice that the system creates the two attributes SYSTEM:Created and SYSTEM:Owner--this pair is a good example of two attributes sharing the same group tag. In general we use all capital letters for the group part and lower case letters, possibly initial capital letters, for the field part.
GPDs are named by a string, which may contain white space. xlincks looks for a specific GPD first in your own GPDmaps and then in the list of system GPDmaps. This allows you to override the system GPDs with your own specialized GPDs. Now, if you expand the Empty User 4's GPDmap line, you will get a window with your first GPDmap as in Figure 2.
Replace the <<table>> with the name of the new GPD, person and then move out of the line with ctrl-n. A new placeholder <<gpd>> will appear which we fill in with a one line description of the new GPD, view of person object, as in Figure 3. Now, expand (meta-l meta-e) the description line to get the empty GPD template seen in the bottom of Figure 3.
First, you add a link from the GPDmap by first clicking on the line Empty User 4's GPDmap followed by a click on the line <<gpdmap>> in the empty GPD, then on the Add Link button—resulting in <<gdpmap>> being replaced with a link to Empty User 4's GPDmap.
Second, we need to define the logical structure by describing the logical parts in the person object. Earlier, we defined the person object to contain a name and birth date. Now, move to <<direct>> line in the STRUCTURE section and replace it with the name of our GPD, person. The name of the GPD used in GPDmap must occur at least once in the STRUCTURE part. After moving out of the line, we replace the newly created empty: value with the parts in our person object: name and “birth date”--since the part name includes a space we must use quotation marks (otherwise it would be three parts!).
Third, now that we've defined the structure of the person object, we need to define where to store the information. The ACCESS section of the GPD defines where we store or retrieve the parts of the logical structure. We would like to store the person's name in the IMAGE part and his/her birth date in an ATTRIBUTE called ADDRESSBOOK:Date.
To specify the name component, we move to the <<direct>> in the ACCESS section and replace it with the name (the name of structure part). Then we move out of the line and replace the empty: value with IMAGE. The resulting GPD can be seen in Figure 4. A warning: any omitted ACCESS specification defaults to IMAGE!
To define where we find the “birth date” in the ACCESS part we move the cursor to the name line in the ACCESS section and do an insert closest plural (meta-l meta-i), with the result as shown in Figure 5. Replacing the direct line with birth date (without quotation marks!) and the empty: value line with ATTR ADDRESSBOOK Date gives us Figure 6. Notice that we use the keyword ATTR followed by the group tag (ADDRESSBOOK) and the field tag to define the storage place for birth date in an attribute.
Last, if we would like to try our new GPD, we need to create a place to store the object, say in our LINCKS home directory:
1) Click on the line “Linux on the Road”
2) Do an insert closest plural (meta-l meta-i)
3) Expand the item (using meta-l meta-e or ctrl-left-click)
4) Fill in the GPD as person
5) Expand the same line (person) which should result in a two-line window saying item and empty: birth date as seen in Figure 7.
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
|Trying to Tame the Tablet||May 08, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- New Products
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- Using Salt Stack and Vagrant for Drupal Development
- Validate an E-Mail Address with PHP, the Right Way
- Tech Tip: Really Simple HTTP Server with Python
- New Products
- Ahh, the Koolaid.
19 min 24 sec ago
- git-annex assistant
6 hours 19 min ago
- direct cable connection
6 hours 41 min ago
- Agreed on AirDroid. With my
6 hours 51 min ago
- I just learned this
6 hours 55 min ago
7 hours 26 min ago
- not living upto the mobile revolution
10 hours 17 min ago
- Deceptive Advertising and
10 hours 52 min ago
- Let\'s declare that you have
10 hours 53 min ago
- Alterations in Contest Due
10 hours 54 min ago
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.