+1 On Tue, Oct 23, 2012 at 10:00 AM, Cody Lerum <[email protected]> wrote:
> +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 > >> > -- 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
