Announcement Announcement Module
Collapse
No announcement yet.
Spring Web Flow, AJAX and DWR Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Web Flow, AJAX and DWR

    Does anyone have an example or advice on how to access a bean in flowscope with DWR? I have seen this quote from Keith:

    "Accessing flow execution state asynchronously via a JavaScript-to-Java library like DWR. In this case the flow execution key is submitted to the backend which is responsible for loading the execution from its repository to access the nessary state."

    How is this done? Any pointers?

    Thanks,

    Steve

  • #2
    Check the following tip on how to access the flow execution from outside SWF, e.g. from your servlet/controller handling the Ajax requests:

    http://www.ervacon.com/products/swf/tips/tip1.html

    That combined with Keith's advice should pretty much get you started.

    Erwin

    Comment


    • #3
      Erwin,

      I now have access to the bean I want within the flow execution. Is there any way to make changes to the bean? I am using DWR to add items to a collection, but no modifications to the bean are persisting across requests.

      Thanks,

      Steve

      Comment


      • #4
        Steve,

        Make sure to put the flow execution back in the repository. You shouldn't need to generate a new key.

        Keith

        Comment


        • #5
          The system isn't really designed to allow you to update a flow execution from ouside of SWF. It's certainly possible but you'll have to do a bit of coding. Check the implementation of the FlowExecutor and the FlowExecutionRepositories for some info on how to go about updating the flow execution in the repo after modifying it.

          Erwin

          Comment


          • #6
            I wouldn't say its not designed for it... The method you need to call is repository.putFlowExecution(key, execution). Should be that simple...
            Keith

            Comment


            • #7
              Well, it can be that simple if you're using the 'singlekey' repo, but when using continuations things get a bit more involved and it's not even that clear how it should be done, e.g. which continuation snapshot(s) should be updated?
              That's basically what I was referring to. If you're just pulling info from the flow execution you don't have to worry about all those issues.

              Erwin
              Last edited by klr8; Feb 5th, 2007, 02:24 PM.

              Comment


              • #8
                You just refer to the one with the key that was submitted. The key doesn't have to change, the user of the repository decides when if it does. So even with continuations, it seems pretty straight forward to me.

                Keith

                Comment


                • #9
                  You just refer to the one with the key that was submitted.
                  That's the only option you have. But what if the user did a CTRL-N on the page you're on and then used one of the windows to modify the flow execution using AJAX. That change will also impact the other window since the flow execution keys are still the same. That's the kind of stuff I was thinking of, making it a non-trivial matter in general.

                  Erwin

                  Comment


                  • #10
                    problem

                    Many thanks to SWF team for opening new horizons in Web development. SWF shocks and makes me love it.

                    Consider you try to access flow execution from AJAX or launch/refresh/resume flows through SOAP handlers. In this cases user have to access flow scope when there is no flow execution on server, it is in external sorage, for example DB.

                    The problem is SWF has difficulties with access FlowExecution from outside flow executor:

                    1. We cannot get/put data like executor does, through ConversationManager. Conversation is guarenteed in memory(and visible to conversation manager) during code execution is inside launch/resume/refresh methods. Ajaxs works !between! these calls (session can expire).

                    2. We cannot get/put data through Repository, because, in case of continuations, it works through ConversationManager. To achieve our aims we must reproduce functions of ConversationManager in Repository. Code doubles. May be using ConversationManager inside Repository removes doubling code, but we can't because of p.1. It seems it would be better to use Repository inside ConversationManager... or create some third class, Cache, that holds functionality, shared between ConversationManager and Repository. Also Cache could act as ConversationContainer. Consider SWF works in environment that don't support sessions, for example Web Services.

                    Picture: ConversationManager gives access to conversation in memory, Cache acts as ConversationContainer(defines where and how to store), Repository defines when to store.

                    3. At any rate realization exists, but demands to rewrite both ConversationManager and Repository and surrounding classes. Reusability of existing SWF code is possible, but hard, because some classes(FlowExecutionContinuationGroup for ex.) are not public, but package-local. Strange, looking at most part of realization classes are public.

                    Easiest way is to make FlowExecutionContinuationGroup public and rebuild SWF. Bad way, but fast: overriding Repository and ConversationManager modules mean do 95% same as it already is in sources. Lots of work for 5% of changes. Saying shorter, inheritance blocked => use copy-paste.

                    Steps to access persisted FlowExecution looks like(continuations mode):
                    a) when put data

                    //get conversation key from flowExecutionKey
                    //get continuation key from flowExecutionKey
                    //extract conversation
                    //extract conversation group
                    //extract continuation
                    //extract flow execution
                    //extract active session
                    //extract flow scope
                    // populate flow scope
                    // serialize continuation
                    //persist conversation to DB

                    b) when get data
                    //get conversation key from flowExecutionKey
                    //get continuation key from flowExecutionKey
                    //extract conversation
                    //extract conversation group
                    //extract continuation
                    //extract flow execution
                    //extract active session
                    //extract flow scope
                    //extract data

                    Correct me please if i'm wrong.

                    Comment


                    • #11
                      The problem is SWF has difficulties with access FlowExecution from outside flow executor
                      Yes, but you could use a FlowExecutor from a SOAP WebService endpoint or from an AJAX call handler. In that case you don't have any issues at all.
                      The problem I mentioned above is when want to access a FlowExecution from outside the FlowExecutor that is actually managing that FlowExecution, so as a third party basically.

                      SWF can already work in an environment where there is no HttpSession, e.g. when using the ClientContinuationFlowExecutionRepository.

                      Also remember that a FlowExecutionRepository implementation is not forced to work with a ConversationManager. You could write a completely new FlowExecutionRepository that does exactly what you want, keeping the ConversationManager out of the picture.

                      Some of those classes are package private because they are internal implementation artifacts of other classes. They're not designed to be reused or subclassed.
                      Last edited by klr8; Feb 8th, 2007, 03:22 PM.

                      Comment

                      Working...
                      X