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

[Jonathan Fuerth]

Actually, it would be better if the framework could continue to enforce the "only one page can be the default" and "only one page can be the login page" rules. We could do this in an extensible way by also having Navigation declare the following interface:

    public interface UniquePageRole extends PageRole {}

Then DefaultPage (in Navigation) and LoginPage (in Security) would extend UniquePageRole. The framework would ensure at rebind time that no UniquePageRole was assigned to more than one page within the app. It could do this, and still provide useful error messages when it found duplicates, without actually knowing what the role classes mean.

Then Navigation could get these two new methods:

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

An alternative would be to create annotations like @Unique and @Required that would target the PageRole implementations, but then we wouldn't be able to make the Navigation.getPageByRole() method typesafe. It would have to accept any type of PageRole as its argument.

-Jonathan

On 2013-05-13, at 3:17 PM, Jonathan Fuerth wrote:

> 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
> _______________________________________________
> errai-dev mailing list
> errai-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/errai-dev