Re: [seam-dev] jsf in seam 3

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.