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