AW Talk is the official development team blog for AribaWeb, the Open Source component-based web application development framework for creating rich, AJAX-enabled applications with the absolute minimum of code (and no hand-coded Javascript).

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.


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.