[seam-dev] Seam Faces and replacing pages.xml
I have been thinking about the replacement for pages.xml and this is what I have come up
with.
I think we need some kind of a hierarchal data store based on view id's, where the
data is stored as annotations:
public class ViewDataStore
{
/**
* Adds data to the store.
*/
public <T extends Annotation> void addData(String path, T data);
/**
* Returns all data for the path in order from most specific to least specific. e.g. if
the path is /app/data/MyScreen.xhtml then it will return data for
* /app/data/MyScreen.xhtml
* /app/data/*
* /app/*
* /*
* assuming all of the above have been placed in the store via addData()
*/
public <T extends Annotation> List<T> getAllDataForPath(String path,
Class<T> dataType );
/**
* returns the most specific data for the given path.
*/
public <T extends Annotation> T getDataForPath(String path, Class<T>
dataType);
}
This could then be configured in a variety of ways, with enum and xml support availible
out of the box:
@ViewData
public enum SomeEnum
{
@View("/app/data/*")
@LoginRequired(true)
@SeamManagedTransaction(ENABLED)
APP_DATA,
@View("/app/data/public/*")
@LoginRequired(false)
APP_DATA_PUBLIC;
}
I have not really though about the xml format yet, but it would probably use seam-xml. We
could also add support for the legacy pages.xml format.
Modules would be able to use this data as follows:
@Inject ViewDataStore data;
public void checkSecurity(String currentViewId, boolean loggedIn)
{
LoginRequired required = data.getDataForPath(currentViewId, LoginRequired.class);
if(required != null)
{
if(required.value() && !loggedIn)
{
throw new NotLoggedInException();
}
}
}
This API will probably need to be tweaked a bit, e.g. I would probably add some producers
that let you inject the metadata for the current view directly, but this should be enough
to give a general idea of what I am proposing.
I think this approach has a number of things going for it:
It is extensible, so if a 3rd party module or user code needs to store metadata about a
view they can use the same mechanism as the official seam modules.
It uses annotations to store the data, which fits in very well with configuration via
annotations rather than xml.
It allows for programmatic configuration and does not tie you to a specific configuration
method
Does this sound like a good idea?
Stuart