1 2 Previous Next 19 Replies Latest reply on May 25, 2009 9:04 AM by wschwendt

    generic conversation support

    mikewse

      Does the WebBeans RI expose some way to hook into, or reuse, WebBeans' JSF conversation support? (to be reused by other frameworks and/or plain servlet apps)


      Also, how do Seam nested conversations fit into the picture - will they be implemented in Seam on top of WebBeans or is some generic support for this in the RI?


      Thanks
      Mike

        • 1. Re: generic conversation support
          cpopetz

          I implemented conversational support for Wicket by hooking into the WebBeans core, but it's on my plate to move those hooks into a separate module that's independent of JSR-299 implementation, so that the wicket-webbeans integration can work with other JSR-299 implementations, and when that's done you should be able to hook other view layers up to the conversation scope in a way that works across implementations.


          If you want to see how it's currently done, take a look at the wicket extension

          • 2. Re: generic conversation support
            mikewse

            Good to hear that others are working on this! What do you think is a plausible timeframe for this effort?


            Also, if I understand correctly you are really talking about a completely separate conversation implementation, and not a way to hook into the base of the JSF conversation stuff?
            Are there any efforts to layer the JSF conversation code to support other client layers?


            Best regards
            Mike

            • 3. Re: generic conversation support
              cpopetz

              Mike Wilson wrote on May 13, 2009 20:32:


              Good to hear that others are working on this! What do you think is a plausible timeframe for this effort?


              The next month or so, if I'm lucky. 



              Also, if I understand correctly you are really talking about a completely separate conversation implementation, and not a way to hook into the base of the JSF conversation stuff?
              Are there any efforts to layer the JSF conversation code to support other client layers?

              Best regards
              Mike


              The conversation implementation is really not much of an implementation.  It's just another context, and the WebBeans JSF code propogates the id of whichever one is running through JSF and across redirects with request params.


               

              • 4. Re: generic conversation support
                mikewse

                Clint Popetz wrote on May 13, 2009 20:42:

                The conversation implementation is really not much of an implementation.  It's just another context, and the WebBeans JSF code propogates the id of whichever one is running through JSF and across redirects with request params.

                Ok, sounds reasonable. I thought there might be lots of little devilishly details like conversation timeouts and other stuff that made you want to harden the code in a common codebase, but if it's just a little code then no worries.


                This also relates a bit to my question about nested conversations, which would take a bit more effort to implement, but I guess there is no trace of them in the JBoss RI and they are implemented in Seam as an add-on?


                Best regards
                Mike

                • 5. Re: generic conversation support
                  cpopetz

                  Mike Wilson wrote on May 13, 2009 21:15:


                  This also relates a bit to my question about nested conversations, which would take a bit more effort to implement, but I guess there is no trace of them in the JBoss RI and they are implemented in Seam as an add-on?




                  That's correct.  After finding dragons early on in Nested Conversation caves, I haven't touched them since, so this isn't a big loss to me, but others seem to like them, so they might be implemented at some point.

                  • 6. Re: generic conversation support
                    mikewse

                    Clint Popetz wrote on May 13, 2009 21:21:

                    After finding dragons early on in Nested Conversation caves, I haven't touched them since, so this isn't a big loss to me, but others seem to like them, so they might be implemented at some point.


                    It would certainly be great to have a high-quality framework-agnostic implementation of nested conversations, but yes, it is a non-trivial task to do ;-)

                    • 7. Re: generic conversation support
                      nickarls

                      The current setup in WB is that there is a JSF-based conversation manager that does asynchronous timeouts. There is an interface, ConversationManager that looks like


                         public abstract void beginOrRestoreConversation(String cid);
                         public abstract void cleanupConversation();
                         public abstract void destroyAllConversations();
                         public abstract Set<Conversation> getLongRunningConversations();
                      



                      There is an BeanStore based AbstractConversationManager that does much of the heavy lifting against this but you can inject different conversation terminator and timouts etc. So for a generic JSF-based asynchronous solution you technically you could extend that one and make sure it gets picked up.


                      If you want synchronous destruction, nested conversations etc, you will probably have to implement the ConversationManager interface directly. Nested conversations can be tricky but a should not be impossible now that there is no bijection interceptor.


                      For a non-JSF lifecycle you will have to do everything yourself since the hooks against the conversation manager will be in different places ;-)

                      • 8. Re: generic conversation support
                        gavin.king

                        Does the WebBeans RI expose some way to hook into, or reuse, WebBeans' JSF conversation support? (to be reused by other frameworks and/or plain servlet apps)

                        Not exactly, but you can take advantage of the extensible context model. You can implement your own Context for @ConversationScoped as a portable extension to 299.



                        Also, how do Seam nested conversations fit into the picture - will they be implemented in Seam on top of WebBeans or is some generic support for this in the RI?

                        IMO, experience has shown that nested conversations are not worth the pain. However, again, it's something that can be implemented as a portable extension to 299.

                        • 9. Re: generic conversation support
                          nickarls

                          The portable extensions (modules) are a really cool possibility of 299. We can take the e.g the Excel module and dump it into a OWB based framework (theoretically).


                          Speaking of that, it would be good to have a (Seam internal) standard for modules to identify themselves (e.g. with something in META-INF) so that the framework could locate and list available/active modules at bootstrap.

                          • 10. Re: generic conversation support
                            mikewse

                            Gavin King wrote on May 15, 2009 05:03:

                            IMO, experience has shown that nested conversations are not worth the pain. However, again, it's something that can be implemented as a portable extension to 299.

                            Ah, right. On second thoughts after writing my previous message I was actually starting to think about the relevancy of nested conversations, although very cool in Seam.


                            When you need that kind of functionality you often have some kind of flow though, and then the nesting thing can be taken care of by the pageflow handler.
                            Is that what you also had in mind?

                            • 11. Re: generic conversation support
                              gavin.king

                              I expect that we will port the pageflow support in Seam to 299 quite soon. But that stuff isn't actually using nested conversations at present.

                              • 12. Re: generic conversation support
                                mikewse

                                Gavin King wrote on May 17, 2009 08:13:


                                I expect that we will port the pageflow support in Seam to 299 quite soon.

                                That sounds really really interesting. Being able to pick functionality on a modular basis is perfect for us, as we integrate between a CMS back-end and a custom front-end, and just want to squeeze in exactly the pieces we need and nothing more.



                                But that stuff isn't actually using nested conversations at present.

                                But it takes care of the kind of challenges as illustrated by the hotel booking demo? Ie, restoring the previously selected hotel when backing up in the browser history, etc...


                                (This doesn't need exactly nested conversations, but some kind of saved state per flow step or series of steps, right?)

                                • 13. Re: generic conversation support
                                  gavin.king

                                  The potential to build modular, portable extensions to the environment is one of the main goals of 299.


                                  The booking app has just a single conversation, so this is supported out of the box in 299 in JSF, or with a fairly simple extension in other web frameworks.

                                  • 14. Re: generic conversation support
                                    mikewse

                                    Gavin King wrote on May 17, 2009 18:03:


                                    Mike Wilson wrote on May 17, 2009 13:51:

                                    But it takes care of the kind of challenges as illustrated by the hotel booking demo? Ie, restoring the previously selected hotel when backing up in the browser history, etc...

                                    (This doesn't need exactly nested conversations, but some kind of saved state per flow step or series of steps, right?)

                                    The booking app has just a single conversation, so this is supported out of the box in 299 in JSF, or with a fairly simple extension in other web frameworks.

                                    I'm sorry, I was taking this from memory and mixed things up. The hotel booking demo I was thinking about was actually an extension made by Jacob Orshalick in this RedHat article where he's making a nice illustration of using nested conversations.


                                    It would be really great to hear your thoughts about how cases like these would best be handled when building upon 299!

                                    1 2 Previous Next