[seam-dev] jsf in seam 3

[Clint Popetz]

On Tue, May 5, 2009 at 10:21 AM, Dan Allen <dan.j.allen at gmail.com> wrote:
>
>
> On Tue, May 5, 2009 at 10:31 AM, Clint Popetz <cpopetz at gmail.com> wrote:
>>
>> On Tue, May 5, 2009 at 9:21 AM, Dan Allen <dan.j.allen at gmail.com> wrote:
>> >
>> >
>> > On Tue, May 5, 2009 at 7:59 AM, Clint Popetz <cpopetz at gmail.com> wrote:
>> >>
>> >> On Tue, May 5, 2009 at 6:26 AM, Pete Muir <pmuir at 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).


True, but some things need to be able to instantiate a generic
Messages component to collect messages regardless of the actual bound
component.  So, for example, when the security layer logs someone in
and adds "Welcome #{username}" to the messages, it needs a way to add
this to the view-specific component without knowing what that is.
Ditto the SMPC code with regard to transaction messages.

It gets more complicate with the Manager...but I think most of the
Manager complexity is gone now that WebBeans (and the Wicket WebBeans
extensions) are handling conversation propagation.

-Clint