1 2 Previous Next 20 Replies Latest reply on Nov 4, 2009 7:03 PM by luxspes

    Seam 3: Flash scope and Conversation Scope

      I am very happy to know that JSF 2.0 finally has flash scope something I asked for in Seam a while ago.


      But I would like to know how this new scope is going to be handled in Seam 3. I am hoping that Seam 3 will not use the equivalente @Begin to promote things in Flash scope in to Long conversation scope (that would be, in my opinion, a big mistake that would limit reutilization). I hope that Seam 3 creates its own separate Promotable Flash scope, so that a developer can choose if something in Flash scope is or not, affected by the start of a long running conversation.


      I also hope that Seam 3 has support for Nested Flash inside Nested conversation (as I discussed a while ago) so that conversations can be flash, promotable flash, or born long, depending particular effect that is required.

        • 1. Re: Seam 3: Flash scope and Conversation Scope
          pmuir

          Hi Francisco,


          I suggest you build a prototype for flash scopes based on CDI's support for pluggable contexts - once you have it, please attach it to a JIRA issue, and we can review it there.


          Also, regarding nested conversations, you'll notice these aren't present in the CDI spec, so if you fancy working on support for these using the context SPI that would be great - similarly, attach them to a JIRA and post back here.

          • 2. Re: Seam 3: Flash scope and Conversation Scope
            pmuir

            BTW yes, I agree, we should support the view scope in Seam 3 as a CDI context.

            • 3. Re: Seam 3: Flash scope and Conversation Scope
              pmuir

              Hah, just realized that we are talking about flash scope, not view scope. If you can present a strong use case for needing flash scope as a context into which to store beans, then we can consider it for the main seam distribution, otherwise I think we could keep it as an extension (more on Seam 3 structure to come over the next few weeks).

              • 4. Re: Seam 3: Flash scope and Conversation Scope

                Pete Muir wrote on Sep 13, 2009 21:02:


                Hah, just realized that we are talking about flash scope, not view scope.


                Exactly. Happy to see that you realized that.



                If you can present a strong use case for needing flash scope as a context into which to store beans, then we can consider it for the main seam distribution,


                I kind of considered flash scope support a given thing, after all, if JSF 2.0 supports it, shouldn't Seam 3 do it to? What I was aiming for with this thread was an assurance that non promotable temporary running conversations (also known as flash scope) are going to be available, and that Seam 3 is not going to promote those to long running conversations. In other words, that Seam 3 is going to have a clear separation between temp conversation scope and flash scope.



                otherwise I think we could keep it as an extension (more on Seam 3 structure to come over the next few weeks).


                AFAIK the only difference between flash scope and temporary conversation scope is that objects in flash scope can not be promoted to be in a long running conversation, and that makes it possible to reuse information exchange logic that works outside long running conversations inside them, the problem I see is that right now there is no easy way to pass information from one request in to the next (and only to the next) if one is inside a long running conversation because one is forced to keep that information stored as long as the long running conversation lasts.


                In other words, a long running conversation is as limited as the session because is no easy way to exchange short lived information once one is inside a long running conversation, and I think flash scope would be a nice solution for that.


                The same logic applies to nested conversations: Why if I start a nested conversations it starts long by default? why I can not have temp nested conversations that would make it easier to pass information only to the next request? and finally, why not also have a nested flash scope for that nested information that never needs to be promoted to a long nested conversation?

                • 5. Re: Seam 3: Flash scope and Conversation Scope
                  gavin.king

                  Pete, JSF introduced a flash scope. Now, personally, I think the whole notion of flash scope is semi-broken (imagine what happens if the expected redirect never actually makes it to the server!), but I don't see why we couldn't have support for it as Seam3.

                  • 6. Re: Seam 3: Flash scope and Conversation Scope

                    Gavin King wrote on Sep 18, 2009 21:16:


                    Pete, JSF introduced a flash scope. Now, personally, I think the whole notion of flash scope is semi-broken (imagine what happens if the expected redirect never actually makes it to the server!)


                    Mmmmm I am not sure I understand... The redirect never actually making it to server risk... is also affects in temp. conversations... no? does that mean those are also semi-broken?



                    but I don't see why we couldn't have support for it as Seam3.


                    Happy to read that!


                    • 7. Re: Seam 3: Flash scope and Conversation Scope
                      gavin.king


                      Pete, JSF introduced a flash scope. Now, personally, I think the whole notion of flash scope is semi-broken (imagine what happens if the expected redirect never actually makes it to the server!)


                      Mmmmm I am not sure I understand... The redirect never actually making it to server risk... is also affects in temp. conversations... no? does that mean those are also semi-broken?


                      Of course it doesn't. A conversation has an id. Which means its state doesn't leak. A flash does not have an id, at least not in rails. Sheesh, you're out there criticizing the design chosen in Seam (which much thought went into) without actually understanding its advantages.


                      • 8. Re: Seam 3: Flash scope and Conversation Scope

                        Gavin King wrote on Sep 21, 2009 18:23:




                        Pete, JSF introduced a flash scope. Now, personally, I think the whole notion of flash scope is semi-broken (imagine what happens if the expected redirect never actually makes it to the server!)


                        Mmmmm I am not sure I understand... The redirect never actually making it to server risk... is also affects in temp. conversations... no? does that mean those are also semi-broken?


                        Of course it doesn't. A conversation has an id. Which means its state doesn't leak. A flash does not have an id, at least not in rails.


                        Oh, I only care about the end result (being able to pass information from one request in to the next without exposing it in the query string, or risking keeping it the session for longer time than needed), if Rails implements it wrong, well, then lets not repeat their mistakes ;-)




                        Sheesh, you're out there criticizing the design chosen in Seam (which much thought went into) without actually understanding its advantages.



                        I do not see the relationship, my criticism is because there is no easy way to pass information from one request in to the next (and only to the next) if one is inside a long running conversation because one is forced to keep that information stored as long as the long running conversation lasts. Are you saying that is not true?


                        Also note I proposed non promotable (leak free) temp. conversations a while ago, but that proposal was ignored.


                        RedHat seems to be part of the expert group for JSF 2.0, if flash without an id is such a bad idea I hope you guys did whatever was in your power to make its implementation leak free.


                        And finally, I criticize because want Seam 3 to be a more complete product, and specially one that is easier to use, if anything I wrote was rude I apologize.

                        • 9. Re: Seam 3: Flash scope and Conversation Scope
                          gavin.king

                          I do not see the relationship, my criticism is because there is no easy way to pass information from one request in to the next (and only to the next) if one is inside a long running conversation because one is forced to keep that information stored as long as the long running conversation lasts. Are you saying that is not true?


                          Alright, so you want to use a redirect inside a long-running conversation, and have things that are cleaned up after the redirect occurs. That was really, really not at all clear from what you've written above! I've never really seen much use for this myself, but I suppose it could be useful.


                          Also note I proposed non promotable (leak free) temp. conversations a while ago, but that proposal was ignored.


                          When I look at that thread, I see two guys talking about totally different things, and not beginning to explain in a concrete way with actual examples, what it is they are trying to do. You need to talk at a waaaay less abstract level if you want people to understand what it is you are trying to describe and have people actually pay attention.


                          Now I notice that somewhere in this thread you did indeed write:



                          problem I see is that right now there is no easy way to pass information from one request in to the next (and only to the next) if one is inside a long running conversation

                          but you had that key piece of information wrapped up in so much philosophizing that it was extremely easy to miss. And you didn't give an example use case.


                          if anything I wrote was rude I apologize.


                          No you weren't rude, its just that what you wrote had more the character of a rant than of an actual concrete feature request. Which is frustrating to read and try and make sense of.

                          • 10. Re: Seam 3: Flash scope and Conversation Scope

                            Gavin King wrote on Sep 21, 2009 20:29:


                            Alright, so you want to use a redirect inside a long-running conversation, and have things that are cleaned up after the redirect occurs. That was really, really not at all clear from what you've written above! I've never really seen much use for this myself, but I suppose it could be useful.


                            That is exactly what I want! I would be very useful.  Right now, if I want to reuse any code that is based on the behavior of temp. conversations  inside a long running one it fails. But I am not sure of how to come up with a concrete example without explaining too much of my system...


                            All I want is to be able to define the way some pages exchange information, and be sure that behavior will not change if I visit those pages and a long running conversation happens to be active in the background at that time.


                            But I guess I am going abstract again...




                            No you weren't rude, its just that what you wrote had more the character of a rant than of an actual concrete feature request. Which is frustrating to read and try and make sense of.


                            Ok, I'll try to be a lot more concrete next time... I guess my problem is that it is precisely when I am frustrated that I think if it were possible to do X this would be so much easier... and I feel that explaining all my system is going to take to much, so I try to save time (and words) by going abstract.

                            • 11. Re: Seam 3: Flash scope and Conversation Scope
                              gavin.king

                              I can see the appeal of this.

                              • 12. Re: Seam 3: Flash scope and Conversation Scope

                                And so JBSEAM-4421 is created

                                • 13. Re: Seam 3: Flash scope and Conversation Scope
                                  asookazian

                                  JSF 314 states:


                                  6.1.4.1 Flash
                                  The Flash provides a way to pass temporary objects between the user views generated by the faces lifecycle. Anything
                                  one places in the flash will be exposed to the next view encountered by the same user session and then cleared out..



                                  So the use case in point is a two-page JSF page flow (as opposed to a 5 page wizard which would be modeled using LRC).


                                  So what exactly is the difference b/n flash scope and a temporary conversation?  The temp conversation is destroyed after redirect, no?


                                  The idea seems to be: you have a LRC that needs to temporarily become flash scope and then what?  Convert back to LRC?  I don't quite follow.  Why can't you simply null out the objects that are no longer required in the 2nd JSF page?


                                  The JIRA above does not provide a concrete example use case (scenario) in which this would be required/useful...


                                  I would expect that any new scopes that JSF 2.0 introduces (including the custom scopes) should be supported out-of-the-box by Seam 3.  But that is obviously up to debate.


                                  http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/#scopes-custom


                                  B/c Seam eliminates the managed bean from JSF completely (and is directly replaced by a POJO or SFSB, for example), I'm not sure how support of custom scopes exactly would be handled but possibly via annotations at the type level for the Seam components.

                                  • 14. Re: Seam 3: Flash scope and Conversation Scope

                                    Arbi Sookazian wrote on Oct 05, 2009 07:17:


                                    JSF 314 states:

                                    6.1.4.1 Flash
                                    The Flash provides a way to pass temporary objects between the user views generated by the faces lifecycle. Anything
                                    one places in the flash will be exposed to the next view encountered by the same user session and then cleared out..



                                    So the use case in point is a two-page JSF page flow (as opposed to a 5 page wizard which would be modeled using LRC).


                                    Yes, I think you could say that.



                                    So what exactly is the difference b/n flash scope and a temporary conversation?  The temp conversation is destroyed after redirect, no?


                                    From a behavioral point of view, AFAIK, there is no difference, but apparently, some implementations this behavior have problems:




                                    Gaving King wrote:
                                    Now, personally, I think the whole notion of flash scope is semi-broken (imagine what happens if the expected redirect never actually makes it to the server!)



                                    And apparently Seam avoid this problem because of its use of an id:



                                    Gaving King wrote:
                                    Of course it doesn't. A conversation has an id. Which means its state doesn't leak. A flash does not have an id, at least not in rails.


                                    This makes me think that this an implementation problem (apparently flash scope, to work correctly, without leaks, needs an id



                                    The idea seems to be: you have a LRC that needs to temporarily become flash scope and then what?  Convert back to LRC?  I don't quite follow.


                                    No, that is not the idea, the idea it to be able to pass information from one request to the other and temp conversation do, but while inside an LRC.



                                    Why can't you simply null out the objects that are no longer required in the 2nd JSF page?


                                    Of course I can, in fact, that is exactly what both Temp Conversations an LRCs do, they store stuff at the session and simply null out the objects that are no longer required when the conversation is over. But AFAIK the point if using a framework like Seam is reduce the effort needed to implement this behavior.




                                    The JIRA above does not provide a concrete example use case (scenario) in which this would be required/useful...




                                    Think about a use case (scenario) where flash is useful. Now think you want to reutilize that code
                                    for that use case, but while an LRC is running. One possible example in during you 5 page wizard, you might need to pass some information that is generated in page 2, and relevant for page 3 but after that is no longer needed.





                                    I would expect that any new scopes that JSF 2.0 introduces (including the custom scopes) should be supported out-of-the-box by Seam 3.  But that is obviously up to debate.



                                    I would expect that too.





                                    B/c Seam eliminates the managed bean from JSF completely (and is directly replaced by a POJO or SFSB, for example), I'm not sure how support of custom scopes exactly would be handled but possibly via annotations at the type level for the Seam components.



                                    AFAIK Seam does not eliminate the need for managed beans in JSF, what it eliminates is the need to define them at faces-config.xml (and makes it possible to define them, by simply adding the @Name annotation). And support for custom scopes, I think, will be available as one of the features that the WebBeans API provides.

                                    1 2 Previous Next