Lianja is all about ART

PDF Print E-mail

When we set out to develop Lianja we took a complete clean room approach to the overall product rather than looking at any existing technology and trying to copy it. With all of the (mis)information available on the web and a wealth of products out there our goal was to produce something unique that would appeal to both casual and professional programmers alike.

We had to develop something that would fit into the modern UIs that were surfacing on tablets and smartphones too but still provide a good user experience on desktop and web.

Some people "get" the Lianja Architecture quickly but for some others it takes a while to understand why Lianja does things the way it does.

At the core of Lianja is the concept of ART. Actions, Rules and Transitions. Now you may be thinking, well there is nothing new in that, after all isn't that the way event driven UIs have been built for years. To some extent that is partially true, but Lianja however views the whole of the UI as a collection of visual elements that can operate independently. Their state is affected by Actions. Lianja filters these actions based on Rules that then cause some Transition to occur in the App.

In a traditional desktop event driven App, users click on buttons, select menuitems etc which cause the App to progress through various UI states.

In Lianja however, An App is made up of pages, and pages are made up of sections. There are a wide variety of built-in sections available; Form, Grid, Image Strip, WebView, TabView, Attachments, Canvas and Custom. See this blog article for an overview of the Lianja App Architecture.

Each of these we will refer to as Visual Elements very similar to the way an HTML5 document can be broken down into sections and articles.

Lianja is all about data. All of the Visual Elements can render data in one way or another e.g. a Form Section consists of FormItems and Gadgets each of which can be bound to data coming from a database, a WebView has a dynamic URI which causes it to render its contents from the web or the Lianja Cloud Server.

Sections are related together using the Relationship Builder which provides developers with the ability to relate Visual Elements together in a meaningful fashion for the particular App.

Page Components in Page Builder

An Action results in the content and/or appearance of these Visual Elements to change through a Transition. For example, in the sample lianjademo App which ships with the product, data navigation actions cause the contents of the Customers section to change. This change in the contents of the customers data displayed causes Lianja to evaluate the Rules associated with that Visual Element. This results in the Orders grid section to be updated with records associated with the particular Customer. We call this a Transition.

As the data in the Orders grid section changes, this then cascades down through the data relationships by dispatching an Action to other Visual Elements, in this case the Orders grid section which results in the Order Details grid section to transition into a new state also and display the order details for a particular order.

Once all sections (and gadgets within Form sections) are in the new state, Lianja then looks to see if there is any right sidebar enabled on the current page and if there is it dispatches an Action to the sidebar which causes it to transition into a new state and recreate its contents based on the current data in the sections of the page.

Note that the Relationship builder supports one-to-many relationships.

In the lianjademo App, this results in dispatching web requests to google charts to refresh the contents on the charts. Note that Lianja makes extensive use of { expression } macros which can be specified as part of the URL to any WebViews or sidebar gadgets.

Actions can occur automatically e.g. each section can have a refreshinterval specified in the attributes dialog which causes Lianja to dispatch the Action to the Visual Element (in this case a section) and it will be processed according to the ART architecture.

Additionally, many other Actions that occur (e.g. due to data changing) can cause Lianja to call a custom delegate that the developer has specified to effect a further transition in the App.

As we progress with Lianja Mobile you will see more of the use of the Lianja ART architecture and understand why it has been architected this way.

It is important to understand the concept of Lianja ART as it will reduce your development times immensely.

Enjoy.

See Also

Lianja Developers Guide
Lianja Documentation Wiki