Working on the booking example has allowed me to gain a perspective about what services we need right away out of the faces (jsf) module. Perhaps it can be removed once the next rev of the EL is ready, but for now we need JBoss EL to get parametrized EL expressions. That means providing a custom JSF Application factory. Fortunately, overriding the default Application impl got way simpler in JSF 2.0 since the spec now provides a base implementation class that you can override a single method at a time. We can eliminate these overrides as they come available in the platform. But for now we need it. ...that brings me to my next very important point. I think we need to be developing against the JSF trunk. The last release, PR2, does not have any of the features that we recently contributed, making development against PR2 almost pointless. I would like to compile a JSF release, call it 2.0.0-PR2_1 (or suggest another version number), deploy it to the JBoss repository, and Seam can depend on that for now. If there are no objections, I will do that today.

Going back to the faces module, instead of continuing with the org.jboss.seam.jsf and org.jboss.seam.faces package split in Seam 3, I think we should put all the faces classes under org.jboss.seam.faces and use appropriate sub-package names. So in this case, I propose org.jboss.seam.faces.application.SeamApplicationFactory and org.jboss.seam.faces.application.SeamApplication for overriding the default Application impl. We will also need the org.jboss.seam.el package (perhaps module).

-Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan 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. ------------------------------------------------------------------------ _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

Going back to the faces module, instead of continuing with the org.jboss.seam.jsf and org.jboss.seam.faces package split in Seam 3, I think we should put all the faces classes under org.jboss.seam.faces and use appropriate sub-package names. So in this case, I propose org.jboss.seam.faces.application.SeamApplicationFactory and org.jboss.seam.faces.application.SeamApplication for overriding the default Application impl. We will also need the org.jboss.seam.el package (perhaps module). +1 for this idea. The module dependencies are turning out to be quite difficult to unravel, if we put our foot down and say that all faces-related/dependent functionality just goes in the faces module this will greatly help to simplify things. I think it's just a matter of zooming out to look at the bigger picture when things seem like they are in a twist. 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.

-Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan 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. _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

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.

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.

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. -Clint _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

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.

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.

Now why would someone really mix Wicket and JSF together in a single app?

In addition, if you do want to allow that runtime selection and allow users to mix and match different view frameworks at runtime, then you need to think about a page that has both JSF and Wicket elements on it, for example a portal style app. Then you really need to think about who consumes what/when.

cheers, Drew Kutcharian Chief Technology Officer Venarc Inc. www.venarc.com Phone: 818-524-2500 On May 26, 2009, at 9:59 PM, Dan Allen wrote: Regarding the discussion of the design for StatusMessages... On Tue, May 5, 2009 at 7:59 AM, Clint Popetz <cpopetz(a)gmail.com&gt; wrote: > 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 have taken a first stab at solving this problem. I'm open to other approaches, but first let me explain what I've done. As Clint points out, from one request to the next, you may be dealing with different frameworks (Wicket vs JSF for instance). But within the request, you want to be able to take specific actions relating to the current framework. Clearly, this is not the appropriate scenario for a deployment type since that is design for a setting/environment that is fixed. So I did some brainstorming. What I realized is that StatusMessages are really a generic repository that should be updated and consumed by the framework-specific activity. Therefore, it seems to me like there should be one and only one conversation-scoped StatusMessages. Then, if you want to have some extra methods for convenience (for instance in JSF to add a StatusMessage from an existing FacesMessage) you create a class which extends and wraps the StatusMessages component (StatusMessages would be injected into it and all overrides delegating to it). You could also override the onBeforeRender() method where you might put the logic for converting and transfering to the native message type and storage. The executor of that conversion would be implemented in the framework-specific listener. For instance, 9 out of 10 times you simply inject the StatusMessages to use in your application: @Current StatusMessages statusMessages; For JSF, there is a FacesMessages bean which inherits from StatusMessages (to keep the API the same) and delegates calls to the StatusMessages instance. It also adds the logic to create FacesMessage objects in the onBeforeRender() method public void onBeforeRender() { super.onBeforeRender(); // create FacesMessage objects and register them here } The ConvertStatusMessagesListener (a JSF system event listener) executes the onBeforeRender() call. manager.getInstanceByType(StatusMessages.class, new AnnotationLiteral<Faces>() {}).onBeforeRender(); There are also some convenience methods on the FacesMessages instance. If you want to use them, you inject as follows: @Faces FacesMessages facesMessages; I can't use @Current here because otherwise the resolution would be ambigous. I could just clone the StatusMessages API in the FacesMessages class to avoid having to use this binding type, so if you have a feeling/advice there, I would be glad to here it. Okay, that's one approach. Now for something different. There is a similar specialization w/ the Expressions class (an EL convenience API). If working within the JSF request, we want to override some methods so that the bean uses the current JSF EL context. In this case, I decided to try Clint's approach described in the cited issue report. A producer method will locate beans that have the binding type @RuntimeSelected and will consult the isActive() method to determine which one is prepared to handle the current request. The isActive() method comes from the RuntimeSelectedBean interface. So the bean must have both the binding type and the interface. There is a second binding type, @Default, which indicates which implementation should be used when there are no @RuntimeSelected implementations present or active. It is mutually exclusive with @RuntimeSelected. So you have: public @Default class Expressions { ... } public @RuntimeSelected class FacesExpressions extends Expressions, RuntimeSelectedBean { public boolean isActive() { return FacesContext.getCurrentInstance() != null; } } public @RuntimeSelected class WicketExpressions extends Expressions, RuntimeSelectedBean { public boolean isActive() { return Application.exists(); } } The producer type for the Expressions bean is application-scoped and the producer method is dependent-scoped (or request-scoped?). The available instances are looked up when the producer is initialized and the instance is selected from this set each time the producer is resolved. Of course, I could have used this strategy for the StatusMessages too, except in the case of StatusMessages it is logical to use the shared/generic StatusMessages bean. It's only when you need to convert the messages do you need the specialization and therefore I think we can avoid having to do the runtime selection. I've committed all of this to the Seam trunk if you want to check it out. I'm open to suggestions...I'm just trying to get used WB and find a workable approach. The solutions we decide on are important because the define a standard practice we will follow as more cases arise. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan 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. _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

Regarding the discussion of the design for StatusMessages... On Tue, May 5, 2009 at 7:59 AM, Clint Popetz <cpopetz(a)gmail.com&gt; wrote: 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 have taken a first stab at solving this problem. I'm open to other approaches, but first let me explain what I've done. As Clint points out, from one request to the next, you may be dealing with different frameworks (Wicket vs JSF for instance). But within the request, you want to be able to take specific actions relating to the current framework. Clearly, this is not the appropriate scenario for a deployment type since that is design for a setting/environment that is fixed. So I did some brainstorming. What I realized is that StatusMessages are really a generic repository that should be updated and consumed by the framework- specific activity. Therefore, it seems to me like there should be one and only one conversation-scoped StatusMessages. Then, if you want to have some extra methods for convenience (for instance in JSF to add a StatusMessage from an existing FacesMessage) you create a class which extends and wraps the StatusMessages component (StatusMessages would be injected into it and all overrides delegating to it). You could also override the onBeforeRender() method where you might put the logic for converting and transfering to the native message type and storage. The executor of that conversion would be implemented in the framework-specific listener. For instance, 9 out of 10 times you simply inject the StatusMessages to use in your application: @Current StatusMessages statusMessages; For JSF, there is a FacesMessages bean which inherits from StatusMessages (to keep the API the same) and delegates calls to the StatusMessages instance. It also adds the logic to create FacesMessage objects in the onBeforeRender() method public void onBeforeRender() { super.onBeforeRender(); // create FacesMessage objects and register them here } The ConvertStatusMessagesListener (a JSF system event listener) executes the onBeforeRender() call. manager.getInstanceByType(StatusMessages.class, new AnnotationLiteral<Faces>() {}).onBeforeRender(); There are also some convenience methods on the FacesMessages instance. If you want to use them, you inject as follows: @Faces FacesMessages facesMessages; I can't use @Current here because otherwise the resolution would be ambigous. I could just clone the StatusMessages API in the FacesMessages class to avoid having to use this binding type, so if you have a feeling/advice there, I would be glad to here it.

Okay, that's one approach. Now for something different. There is a similar specialization w/ the Expressions class (an EL convenience API). If working within the JSF request, we want to override some methods so that the bean uses the current JSF EL context. In this case, I decided to try Clint's approach described in the cited issue report. A producer method will locate beans that have the binding type @RuntimeSelected and will consult the isActive() method to determine which one is prepared to handle the current request. The isActive() method comes from the RuntimeSelectedBean interface. So the bean must have both the binding type and the interface. There is a second binding type, @Default, which indicates which implementation should be used when there are no @RuntimeSelected implementations present or active. It is mutually exclusive with @RuntimeSelected. So you have: public @Default class Expressions { ... } public @RuntimeSelected class FacesExpressions extends Expressions, RuntimeSelectedBean { public boolean isActive() { return FacesContext.getCurrentInstance() != null; } } public @RuntimeSelected class WicketExpressions extends Expressions, RuntimeSelectedBean { public boolean isActive() { return Application.exists(); } } The producer type for the Expressions bean is application-scoped and the producer method is dependent-scoped (or request-scoped?). The available instances are looked up when the producer is initialized and the instance is selected from this set each time the producer is resolved. Of course, I could have used this strategy for the StatusMessages too, except in the case of StatusMessages it is logical to use the shared/generic StatusMessages bean. It's only when you need to convert the messages do you need the specialization and therefore I think we can avoid having to do the runtime selection. I've committed all of this to the Seam trunk if you want to check it out. I'm open to suggestions...I'm just trying to get used WB and find a workable approach. The solutions we decide on are important because the define a standard practice we will follow as more cases arise. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan 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. _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev