(Original creator: eknochs)
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!