hi brian, imo we can keep it short. the type-safe view-config of codi is almost always used also for type-safe navigation. if you exclude that part, it's very hard to compare it to any other approach because that was the central idea in the beginning. -> we could add both and users who have to use e.g. a 3rd party flow-engine would have the choice what they use for the config itself. (-> we would just merge the data-structures for storing the meta-data as well as parts like @ViewMetaData)
regards, gerhard 2012/10/24 Brian Leathem <[email protected]> > On 12-10-23 08:41 AM, Gerhard Petracek 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. >> > > The decision before us is whether to take the Seam Faces approach of > mapping view configuration via a view-id mapping that includes support for > wild cards, vs. the CODI approach of in inheritance hierarchy to > share/group view configuration. > > While the inheritance hierarchy solution maps well when one wants to use > type-safe navigation, it would be good to provide the short-hand for those > who don't want to go all-out with the type-safe navigation approach, but > still want to configure their views (concisely). This is where the Seam > Faces approach fits in well, while not precluding the more verbose approach > that enables type-safe navigation. > > Perhaps we should look at some side-by-side comparisons of the > implementation for specific use cases? This would make it easier to see > how the two APIs compare, and let the community decide which they prefer. > > Brian > > > >> @ summary: >> @ #1 can be supported easily in a type-safe manner (with the approach used >> in codi) >> > > I don't believe the Seam Faces approach is *not* type-safe. Seam Faces > maps view's to enums, and CODI maps views to Interfaces. Both involve a > text -> type mapping. > > > @ #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) >> > > You're talking specifically about navigation here? > > > 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. >> > > The @ViewPattern approach also allows one to inherit configuration. > > > -> i'm still +1 for adding type-safe view-configs described in [1] and add >> further features based on the great feedback we received. >> > > Yes, we need type-safe view configs, I'd like to see us explore more how > the types (irrespective of whether they are enums or interfaces) are mapped > to the views. > > > +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. >> > > +0 here, it doesn't matter to me if we have a dedicated annotation here or > not. > > Brian > > >> regards, >> gerhard >> >> [1] >> https://cwiki.apache.org/**confluence/display/EXTCDI/JSF+** >> Usage#JSFUsage-**TypesafeViewConfig<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+****<https://cwiki.apache.org/**confluence/display/EXTCDI/JSF+**> >>>> Usage#JSFUsage-****TypesafeViewConfig<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/****<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<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 >>> >>> >
