On Tue, May 5, 2009 at 10:31 AM, Clint Popetz <cpopetz@gmail.com> wrote:

On Tue, May 5, 2009 at 9:21 AM, Dan Allen <dan.j.allen@gmail.com> wrote:
>
>
> 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.

I haven't yet seen the work you're doing, so can't patch it easily :P

I'd say that you could go ahead and commit it and I can look
immediately at patching and committing changes to add the runtime
flexibility. Alternatively the above jira has a patch to the previous
seam trunk (pre-cleanup) that is well documented. Or you can send me
your source in patch form pre-commit. The first option is probably
the easiest for both of us.

Everything I have so far is checked in to seam/modules/trunk. But yes, I will review what was proposed for Seam 2 and see if I can work out a solution. I think one way is to change the deployment type to a binding type. That way you do:

@Faces StatusMessages statusMessages;

I was think I had to completely disable the generic messages, but you have clued me into the fact that they can exist simultaneously. That is the purpose of a binding type. In fact, I know this is the right solution. When the messages are transferred before render, only the @Faces StatusMessages will be transfer to the JSF context whereas the @Wicket StatusMessages will be transferred to the wicket context (since you can only render one or the other for any given request).

-Dan