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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev



--
---
Nik