Re: [seam-dev] jsf in seam 3

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