deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [DISCUSS] ViewConfig
Date Tue, 23 Oct 2012 15:45:15 GMT
+1, go for it :)

LieGrue,
strub




----- Original Message -----
> From: Gerhard Petracek <gerhard.petracek@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc: 
> Sent: Tuesday, October 23, 2012 5:41 PM
> Subject: Re: [DISCUSS] ViewConfig
> 
> 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