[errai-dev] Initial version of security module: loginPage vs. page roles feature

[Jonathan Fuerth]

Hi Errai devs,

Erik Jan committed his initial work on the new Errai Security module last week, and asked me to have a look at it. Finally, today, I've been able to do that!

This message contains my remarks on the changes to the navigation framework made in these changesets:

https://github.com/edewit/errai/commit/5fcac9f94295a5260cc69df5fdb3cdec7b59d23a
https://github.com/edewit/errai/commit/9f8a03137513431f7b57605df715dcf12a406c98

With this change to the navigation module, you can now do this:

    @Page(loginPage = true)
    @Templated("#root")
    @Dependent
    public class LoginForm extends Composite {
      ...
    }

I see the need to indicate which page is the login page, but I think there are two less-than-ideal consequences to the way it's been done above: firstly, we now have (conceptually) a cyclic dependency between the Navigation and Security modules; secondly, it would be nice if end users could also define their own page roles. What if we had this instead:

    @Page(role=LoginPage.class)
    @Templated("#root")
    @Dependent
    public class LoginForm extends Composite {
      ...
    }

In fact, role would be declared like this:

  public Class<? extends PageRole>[] role() default null;

so you could have multiple roles on a page. The PageRole type would be an interface, so new subtypes can be added within Errai Navigation but also outside of it. We could even add a new method to the Navigation class:

    public List<PageNode> getPagesByRole(Class<? extends PageRole> role);

With this "role" feature in place, we could deprecate the "defaultPage" attribute on @Page, and provide a DefaultPage class in its place. End users of the framework would now be able to create their own PageRole subtypes and do whatever they want with them. The Security module would declare the LoginPage role class, and the dependency cycle would be broken.

Sound good?

-Jonathan