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 >
