Imagine you have a bunch of web applications you want to make available to your users. You want them all to share the same login and permissions. Actually you’d quite like to have a common look and feel across all of them too.

These applications need to be up 24×7 and you need to be able to update them without bouncing your server. Preferably any time of the day or night.

Your users often have several of these applications active at a time in multiple browser windows and they copy/paste stuff from one to the other. That gets a bit ugly. You would rather when stuff happens in one application the others already know about it. But you don’t want to bind all these applications together, maybe they have different development teams and coordination is too hard.

Let’s assume you don’t have an enterprise authentication system to handle your common login yet, so you need to pop your own login page (but changing to the enterprise authentication system you implement later has to be a minor reconfiguration).

Welcome to Madura Perspectives Manager.

Madura Perspectives Manager is a Vaadin web application which acts as a frame to hold sub applications. The frame has a login page which is skipped if the user is already logged in. Permissions are derived based on the users’ roles using Spring Security and these permissions are propagated to the sub applications.

This is what the frame looks like:

This layout is just an example, you can customise this endlessly if you want, either by changing the CSS settings or by changing the code. The Perspective Manager is just a template or example rather than a fixed product. This version shows:

• Who is logged in.
• A title (top right). This comes from a properties file.
• A logo. This is defined in the CSS file which refers to a logo image. It is fetched using the Vaadin theme mechanism.
• A list of sub applications the frame found when this session started.
• A simple menu (File, Help with an entry under each, in this case Logout and About).

The menu is the basic menu our framework starts out with. This will get added to when we pick a sub application.
So let’s pick a sub application by clicking on the User link on the left.

Now the UI for User displays. That User sub application is not initialised until we first pick it, because you might have a lot of applications and this user in this session might not ever pick them all, so we lazily initialise.

The User sub application is a simple Vaadin Form mapped to an object. It is just a demo so we don’t do much more. But it can get as complicated as you like.

Let’s try the pizza sub application.

If you have looked at our pizza order demo you may recognise this, it is the pizza configuration screen from that demo. Same rules, same objects. So this is a Vaadin application which uses Madura Objects and Madura Rules. It all works the same way, ie if you pick a Size the topping options etc constrain. Required fields are enforced by greying the ‘Save’ button…. oh, wait there is no Save button.

No, but there is an extra option on the menu: Edit. If we open that menu item we will see the Save menu item under it and this is greyed when we have a required field not filled in. These extra menu items appear when we pick this application. We can flick back to the User application and the menu will dynamically redraw leaving out the now inapplicable menu items. If we flick back to the pizza application the menu items will be restored.

There are two other things on this screen that need mentioning.

First the Madura logo appears at the bottom. This is in the space controlled by the sub application. In this case the sub application has done what the frame did, it used a Vaadin theme resource to display an image. What it shows is that the sub application is using the same theme as the frame. You can change the theme for the frame and all the sub applications will change automatically. So you naturally get the same look and feel across the whole collection of applications just by using Vaadin’s themes consistently.

The second thing is the field near the top: User Name. You’ll see that the alignment is a little different. This is because it is not actually part of the pizza form, just a field on the layout. We put it there because it is loosely coupled with the Name field in the User application. if we flick back to User and enter a value in Name, then flick back to pizza we would see that the User Name field has the value we just entered. There is a blackboard system that allows the sub applications to publish and subscribe to information items, thus avoiding that copy/paste annoyance mentioned earlier.

Because these sub applications are Madura Bundles you can add new ones and update old ones (and even delete them) on the fly. Users who have logged in will see the same sub application set until they log out. New users logging in will see the latest sub application set.

Finally a note about permissions. If you’re familiar with Madura Objects you will know that fields can have permissions assigned to them. This, with the permissions assigned to the current user, influences how the fields are rendered (invisible, read-only, read-write). Because the pizza sub application uses Madura Objects the permissions the frame derived from the login are available to the sub application. In fact you can also assign a permission to the whole sub application to allow some users to access it, and refuse access to others.

There is an on-line demo of this on online, although to keep it available to everyone at the same time it doesn’t let you change the bundles around. But you can run it locally too. You just grab the project from GitHub. The bundles are in separate Github projects but that is covered in the documentation.

Why did we call it ‘perspectives’? Because the way the applications switch is a bit like what you see in Eclipse when it switches perspectives.

Enjoy!