[seam-dev] jsf in seam 3

[Dan Allen]

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

-Dan

-- 
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan

NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters.  Please don't hesitate to resend a message if
you feel that it did not reach my attention.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20090505/0006f19c/attachment.html