[seam-dev] Replacing pages.xml

[Nicklas Karlsson]

This could be a path that components.xml could be heading down also? You
could have a SeamConfig bean that could be generated from a XML document,
looked up in JNDI etc that could then be injected wherever needed (or
modified by extensions before taken into use)

On Fri, Feb 19, 2010 at 6:58 AM, Stuart Douglas <stuart at baileyroberts.com.au
> wrote:

>
>
> I have been thinking about the replacement for pages.xml. Even though JSF2
> has made some aspects of pages.xml redundant, pages.xml is still important
> as it allows you to apply actions/security setting etc to a large number of
> pages at once using wildcards. With that said however it would be nice to
> move to a design that is more typesafe and extensible. I have come up with a
> preliminary idea of how this might work, I will explain with an example:
>
> @PageMetadata
> public @Interface SecurityConfig
> {
>   boolean loginRequired();
>   String restrict();
> }
>
> /**
>  * This bean will only be considered for injection when the context path is
>  * /app/restricted/*, and it is the most specific page available.
>  */
> @ViewId("/app/restricted/*")
> @SecurityConfig(loginRequired=true)
> public class RestrictedArea extends Page
> {
>
> }
>
> This may also be configured via XML using seam-xml.
> There is nothing special about the page class, it is an empty class
> that is provided solely to be configured with annotations:
>
> <Page>
>  <ViewId>/app/restricted/*</ViewId>
>  <SecurityConfig loginRequired="true" />
> </Page>
>
> The application can get access to this information in a number of ways:
>
> @Inject PageDataProvider<SecurityConfig> data;
>
> public void doStuff()
> {
>  //get the most specific result
>  SecurityConfig security = data.get();
>
>  //get all applicable results
>  List<SecurityConfig> secinfo = data.getAll();
>
>  //secinfo is ordered from most to least specific,
>  //secinfo.get(0) will be equal to data.get()
>
> }
>
> Alternatively the most specific result can be injected directly:
>
> @Inject SecurityConfig data;
>
> We could also support an event based approach:
>
> public void pageEvent(@Observes @Rendered("/secure/*") Page page,
> SecurityConfig config)
> {
>  //do stuff
> }
>
> Does this sound like a good approach? I am fairly sure all this can be
> implemented as a portable extension.
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>



-- 
---
Nik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20100219/c939532d/attachment-0001.html