3 Replies Latest reply on Dec 6, 2009 4:18 PM by asookazian

    Conversation scope and rich:modalPanel

    meetoblivion

      So I'm wondering if I can get some feedback, maybe I'm heading down the wrong route, not sure.  I'll start off with what it is I'm trying to accomplish.  Think of it like a directory browser, you can see all of the files below the current path, you can go up one, you can view/edit the files there.  I have a rich:modalPanel that pops up when you click on a command link in the page.


      Now, everything works fine when the form and action are session scoped.  however, the code's ugly in my opinion.  there's stuff that resets the form when an action is invoked.  i can't use request scope, it doesn't work correctly (actions invoked due to AJAX requests).  so I figured I'd try out the conversation scope in weld.  i never used it in seam, so it's a new experience for me.


      Based on the example, I created a method


      @Produces @Named("someForm") @ConversationScoped
      public MyForm buildMyForm() {



      where there's a local instance of MyForm that I create and return, all of this ends up in the action class (form is as simple as it should be, getters and setters for all members).  i also being the conversation in there.  i have a save action that ends the conversation as well as a cancel action.  there's a few things I've noticed that don't make sense.


      1. The modal panel never pops up.  The code to do this is a regular action with


      <rich:componentControl for="mdl_pageEdit" attachTo="addPageV" event="onclick" operation="show"/>



      2. So when it doesn't load, instead I get redirected to a page saying that resource /ctxpath/com.my.fqcn.to.class.page?cid=15 is unavailable.  Do conversations require a redirect?


      3. So I hit CTRL R to refresh and I generally get an error about calling begin() on a long running conversation.


      4. Finally, I wonder if I'm not using conversations correctly?

        • 1. Re: Conversation scope and rich:modalPanel
          asookazian

          I've used conversation scope extensively in Seam 2.x apps with RichFaces modalPanel components (just search the Seam forums for proof!)  It's usually not much special you must do for that combo other than refreshing data when users click action links/buttons if there are dataTables/forms embedded in the modalPanels.


          1. What version of Weld and what version of RF are you using? I'm assuming Weld 1.0.0 and RF 4 or RF 3.x (if it's compatible with EE6/Weld?)


          2. I find it almost amazing that you never used conversation scope in Seam before, that's one of the main benefits/features of using Seam along with business process scope for jBPM integration.  For usecases involving multiple HTTP req/resp cycles (like a checkout wizard, etc.), LRCs are ideal.  Also, SMPCs are tied to conversation scope so if you use SMPC and Hibernate manual flush you can avoid LIEs.  In your situation in a Weld app, this feature may be unavailable/irrelevant as it most likely will be a feature of Seam3, a PE of CDI/Weld.


          3. There are actually a couple ways to show a modalPanel.  Check out the RF users forum for info or read Practical RF book.


          4. post any exceptions/stack trace for any errors


          5. In Weld, you must use begin() and end() methods to start and end a LRC, the @Begin and @End annotations will be available in Seam3.

          • 2. Re: Conversation scope and rich:modalPanel
            meetoblivion

            it looks like the underlying issue is that you can't (or shouldn't?) be starting a conversation with something that's @Produces and is called from the UI.  I added an empty method to the bean to fake it out and the modal pops up and everything's status quo again.  i think.

            • 3. Re: Conversation scope and rich:modalPanel
              asookazian

              John Ament wrote on Dec 06, 2009 16:15:


              it looks like the underlying issue is that you can't (or shouldn't?) be starting a conversation with something that's @Produces and is called from the UI. 


              if this is true, why?