Really like both ideas of annotation and view metadata config (less sure about seam-xml
I also think that having a programatic API as a first class citizen (not based around
annotations) is a good idea. Then XML and annotations/enum are just ways to configure it.
On 1 Aug 2010, at 21:36, Jason Porter wrote:
On Sat, Jul 31, 2010 at 09:15, Marcel Kolsteren
> 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.
I really like this idea Marcel. I agree that view specific data
should be in the view. I think we went with the enum idea because you
can't really put it on a bean because there's guaranteed 1:1
relationship between views and backing beans. For JSF the f:metadata
I think makes the most sense, it means one more thing to scan on
application startup however, but I don't think it's that major. I'd
love to see this programmatically extensible as well (so you could
add, remove, edit data via API).
I think the idea of a viewdata.xhtml or something similar is also a
very good and needed idea, otherwise there could be quite a bit of
copy and paste sections.
> 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>
>> This could then be configured in a variety of ways, with enum and xml support
availible out of the box:
>> public enum SomeEnum
>> 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,
>> 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
>> Does this sound like a good idea?
>> seam-dev mailing list
> seam-dev mailing list
Open Source Advocate
PGP key id: 926CCFF5
PGP key available at: keyserver.net
seam-dev mailing list