(Original creator: berryk)


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!

This page has no comments.