5:58 a.m.
I have been thinking about the replacement for pages.xml. Even though JSF2 has made some
aspects of pages.xml redundant, pages.xml is still important as it allows you to apply
actions/security setting etc to a large number of pages at once using wildcards. With that
said however it would be nice to move to a design that is more typesafe and extensible. I
have come up with a preliminary idea of how this might work, I will explain with an
example:
@PageMetadata
public @Interface SecurityConfig
{
boolean loginRequired();
String restrict();
}
/**
* This bean will only be considered for injection when the context path is
* /app/restricted/*, and it is the most specific page available.
*/
@ViewId("/app/restricted/*")
@SecurityConfig(loginRequired=true)
public class RestrictedArea extends Page
{
}
This may also be configured via XML using seam-xml.
There is nothing special about the page class, it is an empty class
that is provided solely to be configured with annotations:
<Page>
<ViewId>/app/restricted/*</ViewId>
<SecurityConfig loginRequired="true" />
</Page>
The application can get access to this information in a number of ways:
@Inject PageDataProvider<SecurityConfig> data;
public void doStuff()
{
//get the most specific result
SecurityConfig security = data.get();
//get all applicable results
List<SecurityConfig> secinfo = data.getAll();
//secinfo is ordered from most to least specific,
//secinfo.get(0) will be equal to data.get()
}
Alternatively the most specific result can be injected directly:
@Inject SecurityConfig data;
We could also support an event based approach:
public void pageEvent(@Observes @Rendered("/secure/*") Page page, SecurityConfig
config)
{
//do stuff
}
Does this sound like a good approach? I am fairly sure all this can be implemented as a
portable extension.
6:31 a.m.
You're probably right that a class is the right thing to use to
represent a page.
But I was actually wondering whether you can use an enumeration to
represent the pages of the app:
public enum MyAppPage implements Page<MyAppPage> {
@View(.....) login,
@View(.....) main,
@View(.....) logout;
public MyAppPage next(MyAppPage page, Object outcome) {
switch (page) {
case login:
if (Boolean.TRUE.equals(outcome))
return main;
else
return login;
case logout:
return login;
case main:
return main;
default:
return page;
}
}
}
where we define the following interface:
public interface Page<X> {
X next(X page, Object outcome);
}
I don't see too much that is immediately wrong with this, but I have
not thought it through properly yet...
On Thu, Feb 18, 2010 at 10:58 PM, Stuart Douglas
<stuart(a)baileyroberts.com.au> wrote:
I have been thinking about the replacement for pages.xml. Even though JSF2 has made some
aspects of pages.xml redundant, pages.xml is still important as it allows you to apply
actions/security setting etc to a large number of pages at once using wildcards. With that
said however it would be nice to move to a design that is more typesafe and extensible. I
have come up with a preliminary idea of how this might work, I will explain with an
example:
@PageMetadata
public @Interface SecurityConfig
{
boolean loginRequired();
String restrict();
}
/**
* This bean will only be considered for injection when the context path is
* /app/restricted/*, and it is the most specific page available.
*/
@ViewId("/app/restricted/*")
@SecurityConfig(loginRequired=true)
public class RestrictedArea extends Page
{
}
This may also be configured via XML using seam-xml.
There is nothing special about the page class, it is an empty class
that is provided solely to be configured with annotations:
<Page>
<ViewId>/app/restricted/*</ViewId>
<SecurityConfig loginRequired="true" />
</Page>
The application can get access to this information in a number of ways:
@Inject PageDataProvider<SecurityConfig> data;
public void doStuff()
{
//get the most specific result
SecurityConfig security = data.get();
//get all applicable results
List<SecurityConfig> secinfo = data.getAll();
//secinfo is ordered from most to least specific,
//secinfo.get(0) will be equal to data.get()
}
Alternatively the most specific result can be injected directly:
@Inject SecurityConfig data;
We could also support an event based approach:
public void pageEvent(@Observes @Rendered("/secure/*") Page page,
SecurityConfig config)
{
//do stuff
}
Does this sound like a good approach? I am fairly sure all this can be implemented as a
portable extension.
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
6:37 a.m.
Oops, this is a MUCH better way to write this code:
public enum MyAppPage implements Page<MyAppPage> {
@View(.....)
login {
public MyAppPage next(MyAppPage page, Object outcome) {
if (Boolean.TRUE.equals(outcome))
return main;
else
return login;
}
},
@View(.....)
main {
public MyAppPage next(MyAppPage page, Object outcome) {
return main;
}
},
@View(.....)
logout {
public MyAppPage next(MyAppPage page, Object outcome) {
return login;
}
};
}
6:40 a.m.
You should even be able to make this work:
@View(.....)
login {
@Inject Login loginBean;
public MyAppPage next(MyAppPage page, Object outcome) {
if ( loginBean.isLoggedIn() )
return main;
else
return login;
}
},
of course we would need a little infrastructure for injecting into enum values.
On Thu, Feb 18, 2010 at 11:37 PM, Gavin King <gavin.king(a)gmail.com> wrote:
Oops, this is a MUCH better way to write this code:
public enum MyAppPage implements Page<MyAppPage> {
@View(.....)
login {
public MyAppPage next(MyAppPage page, Object outcome) {
if (Boolean.TRUE.equals(outcome))
return main;
else
return login;
}
},
@View(.....)
main {
public MyAppPage next(MyAppPage page, Object outcome) {
return main;
}
},
@View(.....)
logout {
public MyAppPage next(MyAppPage page, Object outcome) {
return login;
}
};
}
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
7:36 a.m.
This could be a path that components.xml could be heading down also? You
could have a SeamConfig bean that could be generated from a XML document,
looked up in JNDI etc that could then be injected wherever needed (or
modified by extensions before taken into use)
On Fri, Feb 19, 2010 at 6:58 AM, Stuart Douglas <stuart(a)baileyroberts.com.au
wrote:
I have been thinking about the replacement for pages.xml. Even though JSF2
has made some aspects of pages.xml redundant, pages.xml is still important
as it allows you to apply actions/security setting etc to a large number of
pages at once using wildcards. With that said however it would be nice to
move to a design that is more typesafe and extensible. I have come up with a
preliminary idea of how this might work, I will explain with an example:
@PageMetadata
public @Interface SecurityConfig
{
boolean loginRequired();
String restrict();
}
/**
* This bean will only be considered for injection when the context path is
* /app/restricted/*, and it is the most specific page available.
*/
@ViewId("/app/restricted/*")
@SecurityConfig(loginRequired=true)
public class RestrictedArea extends Page
{
}
This may also be configured via XML using seam-xml.
There is nothing special about the page class, it is an empty class
that is provided solely to be configured with annotations:
<Page>
<ViewId>/app/restricted/*</ViewId>
<SecurityConfig loginRequired="true" />
</Page>
The application can get access to this information in a number of ways:
@Inject PageDataProvider<SecurityConfig> data;
public void doStuff()
{
//get the most specific result
SecurityConfig security = data.get();
//get all applicable results
List<SecurityConfig> secinfo = data.getAll();
//secinfo is ordered from most to least specific,
//secinfo.get(0) will be equal to data.get()
}
Alternatively the most specific result can be injected directly:
@Inject SecurityConfig data;
We could also support an event based approach:
public void pageEvent(@Observes @Rendered("/secure/*") Page page,
SecurityConfig config)
{
//do stuff
}
Does this sound like a good approach? I am fairly sure all this can be
implemented as a portable extension.
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
---
Nik
5180
days inactive
5180
days old
4 comments
3 participants
participants (3)
-
Gavin King -
Nicklas Karlsson -
Stuart Douglas