Tag Archives: XML

Structs: More than just an easy way to process XML streams

Struct

During the sixties of the previous century IBM’s Charles Goldfarb et al. developed, what can be considered now, as the first Markup Language. From his Generalized Markup Language (GML) the more generally known Standard Generalized Markup Language SGML was developed.  Several criteria were defined for this SGML. One of these criteria is that SGML should describe a structure and attributes. By describing it this way it was (and is) much more likely that data can be processed, using (future) information technologies. SGML was designed to process huge documents, initially used by the US government. SGML was often experienced as quite complex and the advent of XML-structured data made it possible to use the concept of structured data for smaller documents as well.

Nowadays XML is indispensable in information technology. XML (and its “mutants” like JSON) can be considered as the “de facto” standard for data communication between applications, using web services and more. In multi-tiered architectures XML should be used for data communication. Each development tool must be able to process XML-like data streams as efficient as possible. Considering XML strings as a “simple” string data type is far too easy to process XML streams in a fast and development-friendly way.

Initially Uniface defined scripting code (formerly known as Proc) that was geared towards the processing of XML. Scripting commands like XMLsave(to place component data in an XML stream) and XMLload (to load data from an XML stream into a component)  are good examples of this kind of scripting code. With the fact that the “data world” was getting more and more complex, these simple statements no longer covered the need for efficient coding. Many Uniface developers used string manipulation coding to process more complex data structures like XML and JSON.

A new paradigm was needed for Uniface to process XML, to stay on top of being (and staying) the number one productivity development tool. With Uniface 9.5 and 9.6 the implementation of the Struct datatype, in combination with the development of scripting code to manipulate Struct datatype variables and parameters (ie “Struct”), was the answer.  A Struct can be defined as a tree-like data structure, kept in memory, that is used to dynamically manipulate complex data and transform it from or to XML or Uniface component data. Variables of type struct are used to access the Struct. Scripting code commands, access operators, and information functions enables the developers to create, build, and manipulate the Struct.

The application of Struct, initially designed to process complex and structured data, has many more options. The creativity of the Uniface software developer is the limit for the application of Structs.  Here is a short list of applications for Struct. The list is just a limited one and without any doubt there are many more applications for Structs.

  • There is complex parameter support of web services and transformations of SOAP messages. All XML strings can, with only one statement, being transformed into a Struct. Struct can be transformed into component data, after some manipulation, if needed.
  • The processing of entities and multiple occurrences has been made much easier and faster. Component data can be transformed into Struct with one command. Because Struct is kept in memory manipulation of is very fast.
  • Software development according to the “multi-tier” paradigm is more straight-forward now. In a well-developed software application communication between the different tiers will be handled using XML, JSON or another XML-like data format. The transformation from component data into Struct is a very simple one.
  • Exchange of JavaScript objects is no longer a serious issue. Uniface has a JavaScript API to enable the development of client-side code for web-deployed applications. JavaScript uses JSON strings for data exchange a lot. Uniface supports the transformation between JSON and Struct. Easy to apply this on communication between a browser-based presentation tier and its server-based back end.
  • Uniface lists can be replaced by the use of Structs. Uniface developers that have developed Uniface list into list (into lists into lists… and so on) know that it can be very complicated and hazardous, using “goldkey ;” and goldkey !” for the lists inside lists definitions. Structs make live much easier.
  • Complex data exchange between entries, operations, and components can be implemented. Both parameters and variables are supported by the struct datatype. Using parameters makes it possible to exchange Struct to-and-from entries, local operations and public operations.

 

This was only a limited bulleted list of possibilities that the newly developed Struct data type offers the Uniface developer with Uniface 9.6. I am very convinced that there are many more creative applications for Structs, please show me!

What else can you use Stucts for?

There is well deserved interest and anticipation in Uniface 9.6, however, I’m still digesting plenty of new things from 9.5.  In particular, I’ve been studying the use of Structs, and the data transformation statements that go with it.

You may recall that Structs were invented primarily to support the processing of complex data types that are used in Web Services.  However, procedural data transformation has much broader application that Web Services.  So even if you don’t plan to integrate with Web Services any time soon, you might have a good reason to use Structs in your legacy applications.

In 9.5 the focus of the data transformation has been on XML and Uniface component data structures.  XML often appears in the payload of SOAP messages used in Web Services, but it is also transported as separate files, sometimes accompanied by XML Schema files.  Some software routine generated these files and some other routine will read and interpret it.  If you consider that there may be file transfer, polling or messaging functions that support the transport of these XML files, then you could view these XML files as a part of an asynchronous call to a software process.  It just isn’t following a formal API, like Web Services.

So let’s compare 2 ways of getting the same job done.  Imagine that you have to build an office document from a template of some kind (to provide layout and pre-defined styles) and from data that is maintained by your Uniface application.  It doesn’t matter if it’s a spread sheet or a textual document.  I am comparing the use of an API, such as COM objects for Microsoft Office, versus the XML file(s) that is stored within the final office document file (these days, Open Office Org, and Microsoft Office documents, are really zipped archives of other files that contain everything needed to reconstruct the document).

API calls may be the safest way to build such a documents, as vendors will often publish an API, along with promises (usually kept)  to keep the API compatible into the future, whilst being free to change document structures without notice (and so their structure is not often documented).

However, a series of API calls may be difficult to comprehend, as the vendor usually has to keep their interfaces at a high level of abstraction and quite generic.  The sequence of calls may not match the way that you have to process your own application data.  At least there is a formal error processing mechanism, even if you find it difficult to understand.  APIs are also potentially limited to certain platforms, or may not have a function that performs the task that you require.

XML files have an orderly structured composition which can be validated.  With some simple viewing tools, it is relatively easy to deduce a document’s data structure.  Prototyping XML file creation is quick as there is visual feedback on how the results appear.  On the down side, you may have built the document structure apparently correctly, but it may still contain errors that will make the document appear corrupt by the next software routine that processes it.  So testing and debugging may be more difficult.

Making a choice between 2 such approaches is made routinely by developers due to many factors.  Now developers can take into account the new Structs data type and data transformation statements.  After building a spread sheet for a customer recently, I’m considering building a tool to massage my iTunes library using Structs, after all, it’s just organizing your assets via an XML file!