[seam-dev] jsf in seam 3

Tue May 5 13:29:21 EDT 2009

On Tue, May 5, 2009 at 1:25 PM, Clint Popetz <cpopetz at gmail.com> wrote:

> On Tue, May 5, 2009 at 12:20 PM, Dan Allen <dan.j.allen at gmail.com> wrote:
> >
> >
> > On Tue, May 5, 2009 at 11:30 AM, Clint Popetz <cpopetz at gmail.com> wrote:
> >>
> >> 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.
> >
> > True. The more a think about it, the more I wonder whether the
> > StatusMessages should be specialized at all. Really it's the translator
> to
> > the native message format that matters.
> >
> > So for instance, let's say in JSF I am listening for the
> preRenderViewEvent
> > or before-redirect event (which is not actually an event, but I know how
> to
> > get my fingers in there). Then, we have a translator which can be
> strongly
> > typed based on @Faces or @Wicket...and in this case I want the @Faces
> one.
> > The translator always consumes the one and only StatusMessages bean.
> >
> > In short, at the point of the translation, you know which translator you
> > want. But the StatusMessages are always generic. Even if we specialized
> > StatusMessages into FacesMessages, the rest of the system would still
> work
> > with the StatusMessages interface...so that would be something seperate.
> > Nevermind it anyway. The point being, the translator should be our
> > specialized interface, not StatusMessages.
>
>
> Agreed, that was my preference in 2.X too, but I couldn't do that and
> preserve backward compatibility with everything that referenced the
> messages components.  I think StatusMessages is view-independent and
> there are separate components that use its contents to do
> view-dependent things.

Excellent. I will give it go. I'm also going to introduce an early wicket
module for Seam that hosts this translator so I can test having the two.
That's all the module will have at this point...then we can think about
where to go with it next.

-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/15d47780/attachment.html 