On Tue, May 5, 2009 at 11:30 AM, Clint Popetz <cpopetz@gmail.com> wrote:
On Tue, May 5, 2009 at 10:21 AM, Dan Allen <dan.j.allen@gmail.com> wrote:
> 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).

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.


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


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.