AribaWeb 101: Playing with rule engine!

Today it’s time for little fun because we are going to play a bit with actual MetaUI engine. So far you might think of this rule engine as the integral part of aribaweb and the only way to work with this was using rules .oss file but it is flexible more than you think. 

If you are kind of person who wants to have things under control and you want know these things also from inside you will definitely check this out. 

Let’s start with something simple! 

Every rule file is loaded and registered once using ValueQueriedObserver. There are several implementations to either load rules out of file or directly from a class using introspection if you have some annotation involved or you let the MetaUI to X-ray your class. For our example we have simple implementation called StringMetaProvider, which takes our  plain string. 

As you can see on the picture below we are creating new context the same thing that happens when you try to render new context using <m:Context inside the awl file.

Every time you try to push new key/value assignment onto the context using set() method the rules matching process is executed and new computed properties map is ready for rendering. 

In example above you can notice once we push all these key/values pairs and we can immediately retrieve the actual value for the label. 

We can go even farther and test how the more specific rules can override less specific rules. 

In this method we added the edit operation, which changes the label. You can think of this as  a switching your UI into editing mode. Here  this new edit operation is pushed onto stack. 
When we ask for the label the rule is already re-calculated and returns correct label. The label should be “Editing Name” 

You might want to checkout the MetaContext class and its method applyValues, renderResponse, invokeAction where everything starts and ends. 

If you are also interested in this StringMetaProvider here you go:

AribaWeb 101: MetaUI continues...

After little break I am pushing this quick how-to, which tries to put some order into your MetaUI project. You know if your project is getting bigger and your number of .oss files increases it can be pretty good mess and here is my little guide how to structure your MetaUI content in order to avoid this.

This short article assumes that you have already read MetaUI documentation and my previous articles. 

You probably remember when you want to render an object into UI you use something similar to this:

and probably your MetaUI rules for this will look like this:

But when the size of your projects gets bigger you need to think differently. Therefore here are some guidelines you want to keep in your mind:

1. Declare your MetaUI class first

Let’s pretend that we have already java class and before you start to do anything on MetaUI side you want to declare your class in .oss file, where you put all your visible fields along with labels, bindings and so on. What you do not want to do is directly to layout your fields in class declaration section like this:

But more like this:

2. Define your UI Groups

As you probably remember the <m:Context can accepts almost any extra key/value pairs which are used later on in the rule matching process. We want to utilize this feature and add extra key that will identify our specific UI context, the actual UI that is going to be rendered. Let’s call it uiGroup. 

uiGroup is extra attribute used to hold specific info for specific page rendering. This way you can have several UI Contexts for one object. 

When you keep this group structure you can easily override what we declared at the beginning and put some specifics only related for this uiGroup. In this case we introduced new field on the fly just for this UI and change label for password field 

3. Define your UI Context in AWL file

Once you have all this above you can finally put your MetaUI context into the awl file followed by uiGroup that identifies your UI part. 

This way you can break down the class declaration from its actual definition for different screens.

Summary

This article might be obvious for most of us but at some point of your project you realize that you need to somehow structure your meta rules and this is one of the option to create your own naming which identifies quickly the uiGroup section. 

Maybe you can go even farther where you can have several .oss files and the name of your .oss file could identifies your specific use case and avoid to have all in one package rules .oss. 

In order to register your own oss file please check out the: 

• ariba.ui.meta.core. Initialization: 
• This class is loaded at the startup when application launches.

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