jsf in seam 3
|
View:
New views
18 Messages
—
Rating Filter:
Alert me
|
 |
jsf in seam 3
by Dan Allen (mojavelinux)
::
Rate this Message:
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@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: jsf in seam 3
by Shane Bryzak-3
::
Rate this Message:
Dan Allen wrote:
> 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. No objections from me. > > 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. > > -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@... > https://lists.jboss.org/mailman/listinfo/seam-dev > _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: jsf in seam 3
by Dan Allen (mojavelinux)
::
Rate this Message:
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@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: jsf in seam 3
by Pete Muir-2
::
Rate this Message:
On 29 Apr 2009, at 07:10, Dan Allen wrote: > > > 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. Exactly, the compex dependency graph exist if you just dump everything in one big heap, it's just not as visible :-) > > > -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@... > https://lists.jboss.org/mailman/listinfo/seam-dev -- Pete Muir http://www.seamframework.org http://in.relation.to/Bloggers/Pete _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: jsf in seam 3
by cpopetz
::
Rate this Message:
On Tue, May 5, 2009 at 6:26 AM, Pete Muir <pmuir@...> 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@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: jsf in seam 3
by Dan Allen (mojavelinux)
::
Rate this Message:
On Tue, May 5, 2009 at 7:59 AM, Clint Popetz <cpopetz@...> wrote:
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. -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@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: jsf in seam 3
by cpopetz
::
Rate this Message:
On Tue, May 5, 2009 at 9:21 AM, Dan Allen <dan.j.allen@...> wrote:
> > > On Tue, May 5, 2009 at 7:59 AM, Clint Popetz <cpopetz@...> wrote: >> >> On Tue, May 5, 2009 at 6:26 AM, Pete Muir <pmuir@...> 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. -Clint _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: jsf in seam 3
by Dan Allen (mojavelinux)
::
Rate this Message:
On Tue, May 5, 2009 at 10:31 AM, Clint Popetz <cpopetz@...> wrote:
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). -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@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: jsf in seam 3
by cpopetz
::
Rate this Message:
On Tue, May 5, 2009 at 10:21 AM, Dan Allen <dan.j.allen@...> wrote:
> > > On Tue, May 5, 2009 at 10:31 AM, Clint Popetz <cpopetz@...> wrote: >> >> On Tue, May 5, 2009 at 9:21 AM, Dan Allen <dan.j.allen@...> wrote: >> > >> > >> > On Tue, May 5, 2009 at 7:59 AM, Clint Popetz <cpopetz@...> wrote: >> >> >> >> On Tue, May 5, 2009 at 6:26 AM, Pete Muir <pmuir@...> 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. It gets more complicate with the Manager...but I think most of the Manager complexity is gone now that WebBeans (and the Wicket WebBeans extensions) are handling conversation propagation. -Clint _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: jsf in seam 3
by Pete Muir-2
::
Rate this Message:
Hi Clint,
I definitely think this is an objective for Seam 3 - it sounds like you and Dan have some ideas about how to make this happen with the Web Beans core. I would suggest reworking your patch for trunk so we get it committed asap, with some tests. Ping me if you want to discuss ideas... Pete On 5 May 2009, at 12:59, Clint Popetz wrote: > On Tue, May 5, 2009 at 6:26 AM, Pete Muir <pmuir@...> 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@... > https://lists.jboss.org/mailman/listinfo/seam-dev -- Pete Muir http://www.seamframework.org http://in.relation.to/Bloggers/Pete _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: jsf in seam 3
by Dan Allen (mojavelinux)
::
Rate this Message:
On Tue, May 5, 2009 at 11:30 AM, Clint Popetz <cpopetz@...> wrote:
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. -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@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: jsf in seam 3
by cpopetz
::
Rate this Message:
On Tue, May 5, 2009 at 12:20 PM, Dan Allen <dan.j.allen@...> wrote:
> > > On Tue, May 5, 2009 at 11:30 AM, Clint Popetz <cpopetz@...> wrote: >> >> On Tue, May 5, 2009 at 10:21 AM, Dan Allen <dan.j.allen@...> wrote: >> > >> > >> > On Tue, May 5, 2009 at 10:31 AM, Clint Popetz <cpopetz@...> wrote: >> >> >> >> On Tue, May 5, 2009 at 9:21 AM, Dan Allen <dan.j.allen@...> >> >> wrote: >> >> > >> >> > >> >> > On Tue, May 5, 2009 at 7:59 AM, Clint Popetz <cpopetz@...> >> >> > wrote: >> >> >> >> >> >> On Tue, May 5, 2009 at 6:26 AM, Pete Muir <pmuir@...> 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. -Clint _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: jsf in seam 3
by Dan Allen (mojavelinux)
::
Rate this Message:
On Tue, May 5, 2009 at 1:25 PM, Clint Popetz <cpopetz@...> wrote:
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 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@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: jsf in seam 3
by Dan Allen (mojavelinux)
::
Rate this Message:
Regarding the discussion of the design for StatusMessages...
On Tue, May 5, 2009 at 7:59 AM, Clint Popetz <cpopetz@...> wrote: I want to 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@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: jsf in seam 3
by Drew Kutcharian
::
Rate this Message:
Dan,
I really like the both approaches and I think method is appropriate for the specific use case the only thing is if all that runtime selection stuff happen per request, wouldn't that be a performance killer? I know the those call times are minuscule, but if that would become a pattern for the rest of the framework, those numbers could really add up. 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, On May 26, 2009, at 9:59 PM, Dan Allen wrote: Regarding the discussion of the design for StatusMessages... _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: jsf in seam 3
by cpopetz
::
Rate this Message:
On Wed, May 27, 2009 at 12:30 AM, Drew Kutcharian <drew@...> wrote:
One example is a code base transitioning from one framework to the other, with a lot of legacy code still in the old framework, and no easy way to split it into separate WARs. Another is two groups operating on separate parts of the same app, each with their own reasons for choosing a view framework.
That's a false dichotomy. Whether JSF/Wicket are interoperable in a portal fashion is orthogonal to whether Seam should assume every request in an app is for one view framework. -Clint
-- Clint Popetz http://42lines.net Scalable Web Application Development _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: jsf in seam 3
by cpopetz
::
Rate this Message:
On Tue, May 26, 2009 at 11:59 PM, Dan Allen <dan.j.allen@...> wrote:
This approach seems fine to me, but I also wonder if composition might be better than inheritance in this case, i.e. StatusMessages is framework independent and not specialized, and provide a separate component subclassed by each framework that propagates the contents of StatusMessages into the view. Most code that injects StatusMessages only wants to add to it messages to it, and the only code that wants to render those messages is in the view framework glue, so they seem like separate concerns. The only reason I didn't go this route in my mods to Seam2 was to minimize changes for backward compatibility.
That approach also looks fine to me, although I should note that with regard to your specific example, Wicket has no notion of Expressions, and so wouldn't specialize it. Wicketeers don't go for EL, as we have nothing that isn't in java :) Now that s/Manager/BeanManager/ is view agnostic, and once StatusMessages is refactored as above, I'm not sure there's a use case for the RuntimeSelectedBean mechanism. Well, yet :) -Clint 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. -- Clint Popetz http://42lines.net Scalable Web Application Development _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: jsf in seam 3
by Pete Muir-2
::
Rate this Message:
On 27 May 2009, at 05:59, Dan Allen wrote: Regarding the discussion of the design for StatusMessages... This is a reasonable approach IMO.
_______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
| Free embeddable forum powered by Nabble | Forum Help |
