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

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/5fcac9f94295a5260cc69df5fdb3cdec7b... https://github.com/edewit/errai/commit/9f8a03137513431f7b57605df715dcf12a... 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