On Tue, May 5, 2009 at 7:59 AM, Clint Popetz
<cpopetz@gmail.com> wrote:
On Tue, May 5, 2009 at 6:26 AM, Pete Muir <
pmuir@redhat.com> wrote:
>
> On 29 Apr 2009, at 07:10, Dan Allen wrote:
>> Instead of thinking of replacing the class 1-for-1, think if perhaps there
>> is base functionality that would be relevant for any environment and
>> specific functionality for a framework like JSF. Then, you can create a
>> generic class and then specialize it using a deployment type and
>> @Specializes. Two examples of this so far are
>> StatusMessages/FacesStatusMessages and Expressions/FacesExpressions. I
>> believe that Selector is another candidate for this. There is nothing
>> specific to JSF about a selector, but it just happens to be in the JSF
>> package in Seam 2.1.
I'm glad to see that this type of consideration is being given to
making Seam3 independent of view layer choice. However, I want to
point out that using a deployment type and @Specializes would seem to
place us in the same situation as Seam 2.x with respect to the view
layers co-existing in the same deployment, which
https://jira.jboss.org/jira/browse/JBSEAM-3645 was meant to address.
In other words, I'd rather that the choice of the StatusMessages bean
that will be activated isn't based on deployment type, but rather is
chosen at runtime based on the type of request, using the pattern in
the patch for the above jira issue. Deployment types would of course
still be used to choose which implementations of things like
StatusMessages are available.
I'd be willing to do the work to make that happen, if it can be
coordinated in such a way that I'm not getting in your way.
Ah, good thinking. I was thinking too narrowly. I'm always open to collaboration, and I work well with diff and patch...so if there is a patch you would like to share with me (pre-commit) I would be glad to test it out and discuss with you possible next steps.
-Dan