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