+1
On Tue, Oct 23, 2012 at 9:41 AM, Gerhard Petracek <[email protected]> wrote: > hi @ all, > > @ wildcard config: > with the approach used in codi you can do the same without using strings > (you just configure it for an interface which can be used for 1-n folders > explicitly or implicitly via inheritance) -> we can stay type-safe here as > well. > > @ summary: > @ #1 can be supported easily in a type-safe manner (with the approach used > in codi) > @ #2 with custom enums it can't be completely type-safe, because you would > fail at runtime if you used an enum which isn't a view-config (e.g. the > name is the same, but the package is different) > > with the approach used in codi, the ide helps you to find the > correct/possible view-config-classes (you can even restrict the target to a > specific area of your application) and the compiler ensures that everything > is correct. during the bootstrapping process we only need to check if the > files really exist. > > esp. due to the multiple inheritance via interfaces, you can specify > meta-data like @Page(navigation = REDIRECT) once and it gets inherited (if > you don't overrule it) -> it isn't that verbose as it might sound. > furthermore, it's possible to use it for further features like > ViewNavigationHandler, @View (to mark page-beans and point to the > view-config/s),... which wouldn't be possible with enums. > > -> i'm still +1 for adding type-safe view-configs described in [1] and add > further features based on the great feedback we received. > +0 for adding @FacesRedirect in addition to @Page(navigation = REDIRECT) - > we just didn't do it that way to reduce the amount of different annotations > users have to know. > > regards, > gerhard > > [1] > https://cwiki.apache.org/confluence/display/EXTCDI/JSF+Usage#JSFUsage-TypesafeViewConfig > > > > 2012/10/22 Brian Leathem <[email protected]> > >> On 12-10-18 01:23 PM, Mark Struberg wrote: >> >>> Hi folks! >>> >>> We already discussed this as part of another thread, but it's time to >>> find a final solution >>> >>> What we have so far: >>> >>> in CODI we have interface + annotation based view configs: >>> >>> https://cwiki.apache.org/**confluence/display/EXTCDI/JSF+** >>> Usage#JSFUsage-**TypesafeViewConfig<https://cwiki.apache.org/confluence/display/EXTCDI/JSF+Usage#JSFUsage-TypesafeViewConfig> >>> >>> You basically write your page structure as interface with sub-interfaces >>> and annotate them with features you like to get. >>> A nice feature is that you can write JSF actions like the following >>> >>> Class<? extends ViewConfig> doSomething() { >>> .... >>> return Admin.EditCustomer.class; >>> } >>> >>> Say goodbye to any clumsy String handling... >>> >>> >>> In Seam3 there is a way to write Enums for approaching something similar. >>> Someone has a link for the docs and might join in to explain the strengths >>> and weak spots of this approach? >>> >> >> Seam Faces ViewConfig docs are here: >> http://docs.jboss.org/seam/3/**faces/latest/reference/en-US/** >> html/viewconfig.html<http://docs.jboss.org/seam/3/faces/latest/reference/en-US/html/viewconfig.html> >> >> As you pointed out, the Seam Faces approach uses enums rather than the >> CODI approach with interfaces (although those enums are in turn defined >> within an interface). The enum approach is more concise (and possibly more >> intuitive) than using "Interface.class" as your constant value. However >> interfaces are nice in their support for inheritance, and CODI makes use of >> this inheritence for grouping of pages. >> >> The Seam Faces solution for grouping of pages has two approaches. First >> the wildcard support: >> >> Consider this enum which can be used to consider faces-redirect, security, >> url-rewriting, and transaction support for all "admin" pages: >> >> @FacesRedirect >> @ViewPattern("/admin/*") >> ... >> ADMIN; >> >> What we lose with the wildcard configuration is support for type-safe >> navigation. One would have to define an enum for each type-safe navigation >> result. The Seam Faces solution for grouping of pages in this scenario was >> to define the annotations on the top level enums. Something like: >> >> @ViewConfig >> public interface Pages { >> >> @FacesRedirect >> static enum Public { >> SEARCH, >> ITEM, >> ALL; >> } >> >> @FacesRedirect >> @Admin // Security annotation >> static enum Admin { >> ADMIN, >> ITEM, >> ALL; >> } >> >> } >> >> In summary, the two important aspects to take from the Seam Faces approach >> are the idea of wildcard support, so one can configure views without the >> requirement to maintain a interfaces/enum/class for each view. Secondly >> the concise nature of the enums would be a benefit for type-safe navigation. >> >> Brian >>
