So we have all of this metadata that affects the User Interface (UI): how do we use it? The answer is through the ProSysPlus UI Builders.

In VFP, we subclassed the classes of the framework we used, and stuck a lot of it there. Some of it had to be inserted on actual controls, though: so we created builders that looked at a control or number of controls, looked up the metadata that had to be set, and then set it. The savings in time, in typing, in stronger reading glasses <s> was huge.

Lianja has an object model that, with a few exceptions (enhancement requests are or will be submitted <s>), is very straightforward. We will get those huge saving here, also. Given our focus on apps delivered by the Lianja Cloud Server (desktop browser, mobile), and that these apps will run as JavaScript-based Single Page Application (SPA) apps, what does that mean for metadata? The answer is that data operations still take place on the app server (with Lianja, under the hood, moving data using oData operations), but some UI operations can be offloaded into the JavaScript client. All of that will be managed through Builders, applying Metadata to your UI by attaching calls to PSP Library functions to UI attributes: the metadata follows the data, and the Builders glue the metadata to the UI.

We won't be subclassing UI objects, as when subclassing is implemented in UI objects it will apply only to Desktop applications. When Native applications for Android, iOS and Windows are released, with the VFP runtime integrated, we'll take a look at the effect of subclassing: does it slow performance (which can be an issue on mobile devices) to an unacceptable degree? Because all our UI calls are made through mediator functions, our metadata actions are dynamic when applied by a Builder. The major benefit is not having to run the builder on an application: but how hard is it to push a button and have metadata applied throughout your application? We'll see how it plays out.