The idea of the view data store sounds like a good idea to me. I like the extensibility
and the programmatic configuration.
I'm not sure whether an annotated enumeration would be a good place to store view
metadata. If I understand it correctly, the enum is just an artificial structure created
for storing a collection of view annotations (where the names of the enum elements are
arbitrary). However, the rationale behind annotations in general is to place the metadata
very close to the data where it belongs to. Class metadata is stored where the class is
defined, method metadata is stored where the method is defined, so ... I would expect that
view metadata is stored where the view is defined.
Why don't we store the configuration of views in the views themselves, or at least the
closest to the actual views as we can get? It's clear that the metadata location would
then depend on the view technology. In a JSF context, I would opt for having the view
metadata in the view (xhtml file) itself. This makes it easier for developers to keep the
view metadata and the view in sync. Another advantage is that the metadata does not need
to refer to the data where it belongs to. When the metadata applies to multiple views
(path ends in wildcard), it can be stored in a special "viewdata.xhtml" file,
which applies to all views on the same level or a deeper level in the directory tree.
On Jul 31, 2010, at 6:31 AM, Stuart Douglas wrote:
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
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev