I definitely think this is an objective for Seam 3 - it sounds like
you and Dan have some ideas about how to make this happen with the Web
Beans core. I would suggest reworking your patch for trunk so we get
it committed asap, with some tests.
Ping me if you want to discuss ideas...
On 5 May 2009, at 12:59, Clint Popetz wrote:
On Tue, May 5, 2009 at 6:26 AM, Pete Muir <pmuir(a)redhat.com>
> 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
>> specific to JSF about a selector, but it just happens to be in the
>> 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
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.
seam-dev mailing list