deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cody Lerum <cody.le...@gmail.com>
Subject Re: [DISCUSS] ViewConfig
Date Tue, 23 Oct 2012 16:00:55 GMT
+1

On Tue, Oct 23, 2012 at 9:41 AM, Gerhard Petracek
<gerhard.petracek@gmail.com> 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 <bleathem@gmail.com>
>
>> 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
>>

Mime
View raw message