Hello everyone, a user here. 1+ here as well.
Thanks a lot for all your efforts. I was encouraged to express my point of view to the dev list in #Deltaspike. When you end up with really many traditional navigation rules I strongly feel like that concept scales poorly in two ways disregarding type safety: 1. My computer at work is a normal high end laptop, using Eclipse it lags for 5-10 seconds when I open the xml files to view the rules, even though they are split over several files. I Think this is a testament to how IDE's in general (or perhaps only eclipse) will always have poor support for xml in comparison to writing actual java code. So even though the fault might be not be the xml itself I feel the end experience is the same. 2. The overview is just terrible. The graphical overview is not helpful and I even though all rules are collected in one place I don't really feel I take advantage. Both ways to do the type safe navigation really solves #1 really well but I feel the nestled classes is a superior mechanism for #2. That's because it gives me a very clear hierarchical overview of the navigation. This is actually pretty useful in a large system. Also as a user of CODI variant I first read about the general idea and then came back to look up how to return a constant and to me at least it just made total sense having already grasped the mechanism. But yes, proper documentation should probably not be overlooked. I hope to see this being standard in the future and my prediction is that the codi just might be a little simpler to add IDE support for? Cheers 2012/10/23 Jason Porter <[email protected]> > +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 >
