AribaWeb 101: Intro into MetaUI - The Concept

Finally I am going to start with the most interesting topic which most of you asked for and still asking either directly or on the discussion forum. Maybe you might think that most of the staff we have covered so far was boring. Believe it or not it was really required. You need to have AribaWeb under control in order to move on.

So back to the MetaUI. As you probably know from the documentation MetaUI is all about rule-driven UI and what it means? I think to simply repeat the same thing what you can read on the website would not be enough so I will start from the other end where the main key is to understand the concept now and not being so technical; trying to figure how to render the html table. 

Let's think for the minute in terms of use cases where you have an actor that plays different roles depending on the situation which we will call context. In other words in the real world situation you can have an actor let's call him Frank who is the same person but act or interact differently depending if he is at work or if he comes home. A work is a context or situation and he plays his Developer role here where as at Home context he plays his role Husband. I think everybody understand this one. But how about the software computing? Why we cannot model this in the same way? 

When we try to model the same thing in the software we usually end up with completely different solution. Our person will be probably root object and we will have two derived classes Developer and Husband that is not the same thing as above. Ideally we want to have only one object representing this person Frank and depending on the context we want to dynamically apply specifying behavior which current situations requires. Not even mentioning that UI layer will have probably specific code for this specific situation and everything will be statically known. When Frank is at work he is not acting like husband. That would look weird right? He does not even want to have the behavior available. 

So what we need to have is to somehow dynamically insert a different behavior to an object depending on the context and all this at Run-time. And we are back to AribaWeb and its MetaUI. As this can be mapped to your Domain Model and Business logic and abilities of your programming language or framework to attach at Run-time dynamically different functionality depending on the context (such as Qi4j for java) then the same can be applied on the UI level how you are able to render your user interface depending on the situation for the same type of objects. 

After short let's say conceptual overview let's be more specific and look at what I was talking about. 

Thanks to MetaUI you are able to dynamically render different user interfaces and add it different behavior at the Run-time for an object depending on the specific context. All this is done using our glue that we call Meta rules. The beauty about this is that object which is being rendered has no idea how it is going to be rendered. And the object does not really care. Even your UI code does not have to be aware that it is rendering this specific object. The only thing we do is to push it into a new situation (a context) and based on this situation we attach to it some new behavior, show fields, or create new ad-hoc fields or hide fields, so on.

In above picture we have two different UI screens not really two different HTML pages. Actually the page has no clue what is being rendered. 

Let's break down each layer:

 Generated UI:

As already said inside the page we have just little magic

We just define in your UI code this little fragment, which tells the framework: 

• Create new context for the use case UserSignup or AdminUpdatesUserProfile and the object User 
• Since this is just an example and we go even farther. We do not have to pass a user object. We can pass any objects and based on the type the correct rules set is matched and UI is rendered.

Context:

Context is really a situation you want your data to be rendered for. 

• You pass into context several inputs and based on these inputs the correct rule is matched and the UI is rendered 
• Context accepts any key/value inputs and the number or the key names are not fixed. All is up to you. 

Meta Rules:

• Finally this is the heart of this framework or the glue that puts completely different things together in the Run-time. 
• For the above example this could look like this:

•  First we define the class. You do not have to define every single field here the introspection works well enough.

• Then we can declare rules for every single use case. In the first example we render only two fields so user can sign up. 
• In the second case we show more fields because administrator needs to see everything. 
• You can also define and show field on the fly that are calculated 

What if you want to give your Administrator some restriction so he/she has to first click on the button Edit before any modification? And maybe admin does not want to see exact date but he only cares about number of days from the last modification. 

The UI could look like this: 

*non-editable mode on the left and editable mode on the right.

Let's see what all we have to change to extend this example:

• Added extra key-value pair called operation.
• If admin opens up the screen everything is in read-only mode because our operation is initialized with value "view"
• Then she/he can click on the switch button Edit and all the fields turns into editable format so you can input your data. Easy no?

And in the Meta rules we have modified following:

• We do not have to do anything in case of operation key the framework is handling editability for us. 
• The only change we did now we told the lastUpdated field to render itself as number of day and all this only inside this admin context. 

 

For more details please see MetaUI.

 Summary:

In this article we have covered the concept of the rule driven generated user interface that can be dynamic as much as you wish. Also do not take the inheritance example describing the analogy between real and computing world too serious. If you are smart developer I am sure you would come up with better solution but for the purpose of this article it was sufficient;-)


Last key points to mention:

• Meta rules just like well-known css are cascaded, they can govern layout and also the behavior. 
• Meta rules are additive with more specific rules overriding less specific rules. 

Common rule specifying controller

• Meta rules can fire off object or off context