I like @ViewConfig also, it's less ambiguous than @ViewData. The <f:metadata> idea is great, I really like it. For now though, let's just go with the enum-based configuration and proceed as you suggest Brian by creating a separate JIRA feature request for alternative configuration options.

Agreed, the "data" part sounds too much like application data. I think the only way to get away from that is to drop the data word altogether - "meta" alone seems sufficient.

I propose we keep the annotation as @ViewConfig, and rename the data structures:
ViewDataStore => ViewMetaStore
ViewDataConfiguration => ViewMetaConfiguration

These ViewMeta* classes aren't going to be visible in your run-of-the mill applications anyway. They'll simply have an enum with the @ViewConfig annotation.

I had initially thought of creating a Faces @Restrict tag, that would use EL to grant/deny access to a page.

Shane pointed out we should rather be using the typesafe security annotations from Seam security (an optional Dependency). The app dev would build annotations that are annotated with @SecurityBindingType, and put these annotations in the @ViewConfig enum.

Faces will listen for the PostConstructViewMapEvent, retrieve the list of @SecurityBindingType annotations from the @ViewConfig, then throw a CheckSecuredViewEvent. The Seam Security module will observe it, do the security check, and return a boolean.

Not as straightforward as @Restrict(#

), but type safety is definitely a big benefit.

I recommend putting this code into the "org.jboss.seam.faces.view" package.

Updates for those following along:

1. Class Renames. I renamed @ViewData to @ViewPattern, and everything else is named @ViewConfig[Something], all in the "org.jboss.seam.faces.view.config" package. This naming convention is a strawman proposal - I'd like to get the API working, and put it out there for community feedback.
2. The @ViewConfig annotation enums wan't being picked up by Weld 1.1, so I switched to using an interface, with @ViewPattern annotations on methods. Slightly more cumbersome - but it works!
3. Some ideas for refinements on Security options
   1. timing for security enforcement is (depending on request type):
      initial | postback = AFTER_RESTORE | BEFORE_INVOKE | BEFORE_RENDER
      default timing is
      initial = BEFORE_RENDER, postback = AFTER_RESTORE
   2. view to redirect to on authentication failure:
      1. if not logged in, redirect to a login page
      2. if logged in, and auth fails, redirect to an error page by default, with option of providing an "auth failed view" via anotation or parameter