[seam-dev] Seam Faces and replacing pages.xml

[Pete Muir]

Really like both ideas of annotation and view metadata config (less sure about seam-xml config though).

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.

Pete

On 1 Aug 2010, at 21:36, Jason Porter wrote:

> On Sat, Jul 31, 2010 at 09:15, Marcel Kolsteren <marcel at meandi.nl> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>> 
>> 
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev