UiBinderAutho

Welcome to UiBinderAutho the automatic part of the UiBinderAuth project.

This project is a concrete implementation that uses the low level feature added by UiBinderAuth. While the UiBinderAuth is a fork of the GWT UiBinder with added abilities, this project is a base framework to use that added code interception feature.

Note: at the current state, the API and the "test classes" are mixed together because this project is aimed to be a demo. You can however reuse a lot of classes and interfaces in this code. In any case you'll be obliged to download the sources and adjust the code for your needs. So consider it as a scaffold project for now

The main classes you should look at are the following:

1.  ProfileSpecificWidgetCreator which contains the logic on how to change the look of any widget
2.  fr.onevu.auth.server.auth.Profile you'll have to change this server side class that specifies the behavior of your widgets (this is typically a check of the connected profile, then a database reading of the settings associated to the profile roles)
3.  /Auth/war/profile.jsp this file uses the answer of the server class Profile to load the settings into the page. You must do a <%@include file="profile.jsp" %> in your module html file to be able to grab the info from the server.

This code is the key to understand the initialization process, it's the Module startup code

public class Auth implements EntryPoint {
    public void onModuleLoad() {
        RootPanel profilePanel = RootPanel.get("profile");
        if (profilePanel == null)
            return;

        String rulesJson = profilePanel.getElement().getInnerHTML().trim();
        if (rulesJson == null || 0 == rulesJson.length())
            return;

        ProfileWidgetJsonSerializer jsonSerializer = new ProfileWidgetJsonSerializer();

//here the rules get injected to the client : you can start using UiBinder from now 

      ProfileSpecificWidgetCreator.setProfileWidgetRules(jsonSerializer.deserializeFromJson(rulesJson));

**//by inheriting this module, you can be sure when it comes to your code, all is correctly initialized**
}

Deeper reading

This project is a default implementation of UiBinderAuth, it is in this separate project because it provides some data structure to hold the abstract concepts in UiBinderAuth

Classes declared in this project can be directly reused/extended in your project. You'll have to implement the service that tells the client which field of which UiBinder file has to be handled specifically for the connected user. The server knows who is connected on the other side of the lane, so it can give display directives on GWT application startup. If the user connects or has rule changes, a page reload will be necessary. But this kind of changes is rare enough to justify a page reload.

Cases where the widgets display may be impacted in an application wide context are for example:

• a user with a certain role (manager, visitor, none, administrator)
• a user loosing access to some features (eg. credit insufficient, administrator forbidding functionality to a given user, etc...)
• a user decides to change the styles (personalize his 'desktop' theme)
• the application state changes (maintenance) and allows restricted access
• a bonus temporary feature for the user (for his birthday :-) )
• add tooltips and helps to widgets if the user is new to the platform
• notify the user of warning states on login (that may be consumed after)

Since the library UiBinderAuth is specialized in UiBinder interception, it will not natively work with manually created widgets. But we strongly recommend that each created widget passes through the gateway method ContextSpecificWidgetCreator#init(). This will allow to have a uniform authorization handling controller. This can be achieved through the ClienFactory pattern that is anyway recommended.

Later, this library might include a widget cache, that will make it possible to provide runtime services (as opposed to startup services):

• adding handlers to detect EventBus events related to Widget display mode and update the cached visible widgets
• react asynchoneously by asking to update the information relative to the role/ as display information
• provide an interface with the available widget 'namepsaces' (UiBinder file + field || hand written scope + field) to edit the widget attributes
• allow to display validation messages next to the concerned widget in a central manner (if a widget is detected to have validation issues, it is get from cache and manipulated to display a message next to it) Your help and suggestions are naturally welcome