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: 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




AribaWeb 101: Intro into Session Management



After a short break and really busy time I have decided to put together this quick article which tries to put some light into the Session Management and maybe little about the authentication process within AribaWeb. 

We will start with this simplified object collaboration diagram that captures the request/response process.

**The rectangles represent various objects, which are involved in the communication and the lines between these rectangles represent the relationships (association, composition, dependencies or inheritance) between them. Messages are shown as a labeled arrow that indicated direction of the message. 


Request / Response process - Simplified collaboration diagram 



On the picture above the AWDispatcherServlet dispatches the request depending if it's Direct or Component action into AWRequestHandler impl. class. It then continues down to the AWPage. I think the most interesting part is in the AWRequestContext class which is in the middle of this process where: 



  • It initiates the checks for request as well as the session 
    • Here is the place where your security starts because it calls validation methods from your AWComponent and SessionHandler where you can decide if your session is valid. If you decide that is not valid you can kick user back to your defined login page (showLoginPage() method) 
  • We can also say that from this context AW starts the execution of all three phases (applyValues, invokeAction, renderResponse) even the code itself is inside the AWRequestHandler

Let's check out some example. 

We will continue from my last example where I showed you how to layout your application and do not rely on the flat project structure. So this is my project.


Project structure


I think the explanation for this layout was already written in my previous articles. But lets focus for now on the WebApplication class that registers custom session validator. 

I usually register the session validation logic inside my application (the subclass of the AWServletApplication) just like on the picture bellow. In this case we have SessionHandler called MyLoginSessionhandler.





There are three empty methods for which you should provide your own implementation. The first method requireSessionValidationForAllComponents() turns on/off your validation logic and in this step we are telling the AW that we do not want to validate a session therefore we always jump directly into the app homepage.


LoginPage


What if we want to implement some authentication and have custom login page to be shown if the user is not properly authenticated. It's pretty simple to do because if you remember the diagram on the top we are going to attach our functionality to the process that is invoked by AWRequestContext in the handleRequest() method. And this functionality is going to be enabled inside our MyLoginSessionHandler and our LoginPage


First thing to do is to enable the validation for the components with the requireSessionValidationForAllComponentActions() method and then return the LoginPage for the invalid session. In this case we modified the code the step above (see pic. bellow) and now we always show the LoginPage because the method validateSession() returns false.





Our LoginPage component should also override the shouldValidateSession() method to turn off the validation completely for this LoginPage.






This all cannot really work without storing user specific information into session. This is usually done inside the AWSession that wraps the http session. This is perfect place to store current user or his/her username or anything you do not want to load every time user clicks on the button.



And the login() method logic can look like this:
  • It resets the Navigation Bar state 
  • Initialize the session 
  • Redirect the request back to the homepage
















Once we have this code in place we can modify the SessionHandler to use our new session class. As you can see this is our third modification of this class and now with proper code.


Logoff

Logoff action is going to be really simple. When we decided to use the AWSession we must also follow its rule how the session is closed. For this reason AWSession has method terminate() which does not destroy the session immediately but at the end of the cycle but also  does clean up many things. 





Note: Please never call invalidate() on the HttpSession. The reason is simple while  AW   is trying to render the page it is still using the session and trying to read some stored information from it and when you do invalidate it's gone and your app fail to render the page. 


Other areas to investigate:
Please see this as a pure introduction and if you are serious about the authentication you want to check out how the AWLocalLoginSessionHandler.CompletionCallback works. You will find out that at the end there is something called AWFormRedirect which is also used allot when you are using direct actions.
 

Source code from this article on the request: frantisek@kolar.pro