9:17 p.m.
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
9:27 p.m.
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/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
_______________________________________________
errai-dev mailing list
errai-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev
8:07 a.m.
Hi,
Although I have no clue yet what others would do with these roles I like the abstraction
it brings. Let's do it!
Cheers,
Erik Jan
1:35 p.m.
+1
On 05/14/2013 02:07 AM, Erik Jan de Wit wrote:
Hi,
Although I have no clue yet what others would do with these roles I like the abstraction
it brings. Let's do it!
Cheers,
Erik Jan
_______________________________________________
errai-dev mailing list
errai-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev
4005
days inactive
4006
days old
3 comments
3 participants
participants (3)
-
Eric Wittmann -
Erik Jan de Wit -
Jonathan Fuerth