<div class="gmail_quote">On Tue, May 5, 2009 at 1:25 PM, Clint Popetz <span dir="ltr"><<a href="mailto:cpopetz@gmail.com">cpopetz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Tue, May 5, 2009 at 12:20 PM, Dan Allen <<a href="mailto:dan.j.allen@gmail.com">dan.j.allen@gmail.com</a>> wrote:<br>
><br>
><br>
> On Tue, May 5, 2009 at 11:30 AM, Clint Popetz <<a href="mailto:cpopetz@gmail.com">cpopetz@gmail.com</a>> wrote:<br>
>><br>
>> On Tue, May 5, 2009 at 10:21 AM, Dan Allen <<a href="mailto:dan.j.allen@gmail.com">dan.j.allen@gmail.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> > On Tue, May 5, 2009 at 10:31 AM, Clint Popetz <<a href="mailto:cpopetz@gmail.com">cpopetz@gmail.com</a>> wrote:<br>
>> >><br>
>> >> On Tue, May 5, 2009 at 9:21 AM, Dan Allen <<a href="mailto:dan.j.allen@gmail.com">dan.j.allen@gmail.com</a>><br>
>> >> wrote:<br>
>> >> ><br>
>> >> ><br>
>> >> > On Tue, May 5, 2009 at 7:59 AM, Clint Popetz <<a href="mailto:cpopetz@gmail.com">cpopetz@gmail.com</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> On Tue, May 5, 2009 at 6:26 AM, Pete Muir <<a href="mailto:pmuir@redhat.com">pmuir@redhat.com</a>> wrote:<br>
>> >> >> ><br>
>> >> >> > On 29 Apr 2009, at 07:10, Dan Allen wrote:<br>
>> >> >> >> Instead of thinking of replacing the class 1-for-1, think if<br>
>> >> >> >> perhaps<br>
>> >> >> >> there<br>
>> >> >> >> is base functionality that would be relevant for any environment<br>
>> >> >> >> and<br>
>> >> >> >> specific functionality for a framework like JSF. Then, you can<br>
>> >> >> >> create a<br>
>> >> >> >> generic class and then specialize it using a deployment type and<br>
>> >> >> >> @Specializes. Two examples of this so far are<br>
>> >> >> >> StatusMessages/FacesStatusMessages and<br>
>> >> >> >> Expressions/FacesExpressions.<br>
>> >> >> >> I<br>
>> >> >> >> believe that Selector is another candidate for this. There is<br>
>> >> >> >> nothing<br>
>> >> >> >> specific to JSF about a selector, but it just happens to be in<br>
>> >> >> >> the<br>
>> >> >> >> JSF<br>
>> >> >> >> package in Seam 2.1.<br>
>> >> >><br>
>> >> >> I'm glad to see that this type of consideration is being given to<br>
>> >> >> making Seam3 independent of view layer choice. However, I want to<br>
>> >> >> point out that using a deployment type and @Specializes would seem<br>
>> >> >> to<br>
>> >> >> place us in the same situation as Seam 2.x with respect to the view<br>
>> >> >> layers co-existing in the same deployment, which<br>
>> >> >> <a href="https://jira.jboss.org/jira/browse/JBSEAM-3645" target="_blank">https://jira.jboss.org/jira/browse/JBSEAM-3645</a> was meant to address.<br>
>> >> >><br>
>> >> >> In other words, I'd rather that the choice of the StatusMessages<br>
>> >> >> bean<br>
>> >> >> that will be activated isn't based on deployment type, but rather is<br>
>> >> >> chosen at runtime based on the type of request, using the pattern in<br>
>> >> >> the patch for the above jira issue. Deployment types would of<br>
>> >> >> course<br>
>> >> >> still be used to choose which implementations of things like<br>
>> >> >> StatusMessages are available.<br>
>> >> >><br>
>> >> >> I'd be willing to do the work to make that happen, if it can be<br>
>> >> >> coordinated in such a way that I'm not getting in your way.<br>
>> >> ><br>
>> >> > Ah, good thinking. I was thinking too narrowly. I'm always open to<br>
>> >> > collaboration, and I work well with diff and patch...so if there is a<br>
>> >> > patch<br>
>> >> > you would like to share with me (pre-commit) I would be glad to test<br>
>> >> > it<br>
>> >> > out<br>
>> >> > and discuss with you possible next steps.<br>
>> >><br>
>> >> I haven't yet seen the work you're doing, so can't patch it easily :P<br>
>> >><br>
>> >> I'd say that you could go ahead and commit it and I can look<br>
>> >> immediately at patching and committing changes to add the runtime<br>
>> >> flexibility. Alternatively the above jira has a patch to the previous<br>
>> >> seam trunk (pre-cleanup) that is well documented. Or you can send me<br>
>> >> your source in patch form pre-commit. The first option is probably<br>
>> >> the easiest for both of us.<br>
>> ><br>
>> > Everything I have so far is checked in to seam/modules/trunk. But yes, I<br>
>> > will review what was proposed for Seam 2 and see if I can work out a<br>
>> > solution. I think one way is to change the deployment type to a binding<br>
>> > type. That way you do:<br>
>> ><br>
>> > @Faces StatusMessages statusMessages;<br>
>> ><br>
>> > I was think I had to completely disable the generic messages, but you<br>
>> > have<br>
>> > clued me into the fact that they can exist simultaneously. That is the<br>
>> > purpose of a binding type. In fact, I know this is the right solution.<br>
>> > When<br>
>> > the messages are transferred before render, only the @Faces<br>
>> > StatusMessages<br>
>> > will be transfer to the JSF context whereas the @Wicket StatusMessages<br>
>> > will<br>
>> > be transferred to the wicket context (since you can only render one or<br>
>> > the<br>
>> > other for any given request).<br>
>><br>
>><br>
>> True, but some things need to be able to instantiate a generic<br>
>> Messages component to collect messages regardless of the actual bound<br>
>> component. So, for example, when the security layer logs someone in<br>
>> and adds "Welcome #{username}" to the messages, it needs a way to add<br>
>> this to the view-specific component without knowing what that is.<br>
>> Ditto the SMPC code with regard to transaction messages.<br>
><br>
> True. The more a think about it, the more I wonder whether the<br>
> StatusMessages should be specialized at all. Really it's the translator to<br>
> the native message format that matters.<br>
><br>
> So for instance, let's say in JSF I am listening for the preRenderViewEvent<br>
> or before-redirect event (which is not actually an event, but I know how to<br>
> get my fingers in there). Then, we have a translator which can be strongly<br>
> typed based on @Faces or @Wicket...and in this case I want the @Faces one.<br>
> The translator always consumes the one and only StatusMessages bean.<br>
><br>
> In short, at the point of the translation, you know which translator you<br>
> want. But the StatusMessages are always generic. Even if we specialized<br>
> StatusMessages into FacesMessages, the rest of the system would still work<br>
> with the StatusMessages interface...so that would be something seperate.<br>
> Nevermind it anyway. The point being, the translator should be our<br>
> specialized interface, not StatusMessages.<br>
<br>
<br>
</div></div>Agreed, that was my preference in 2.X too, but I couldn't do that and<br>
preserve backward compatibility with everything that referenced the<br>
messages components. I think StatusMessages is view-independent and<br>
there are separate components that use its contents to do<br>
view-dependent things.</blockquote><div><br>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.<br>
<br>-Dan </div></div><br>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br>
<a href="http://in.relation.to/Bloggers/Dan">http://in.relation.to/Bloggers/Dan</a><br><br>NOTE: While I make a strong effort to keep up with my email on a daily<br>basis, personal or other work matters can sometimes keep me away<br>
from my email. If you contact me, but don't hear back for more than a week,<br>it is very likely that I am excessively backlogged or the message was<br>caught in the spam filters. Please don't hesitate to resend a message if<br>
you feel that it did not reach my attention.<br>