deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Leathem <>
Subject Re: [DISCUSS] ViewConfig
Date Wed, 24 Oct 2012 18:07:04 GMT
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.


> @ 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.


> regards,
> gerhard
> [1]
> 2012/10/22 Brian Leathem <>
>> 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:
>>> 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:
>> 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

View raw message