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