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

On Sat, Jul 31, 2010 at 09:15, Marcel Kolsteren <marcel(a)meandi.nl&gt; wrote: > 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> 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 > > > _______________________________________________ > seam-dev mailing list > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev