2 Replies Latest reply on Mar 12, 2007 4:13 PM by Bernd Ruecker

    Some Commands committed

    Bernd Ruecker Master

      I have committed some of the promised Commands for jBPM a few minutes ago. These are the commands which work with our Swing application.

      The biggest issue to discuss is the depth of the object graph to fetch with the jbpm objects (because Swing can not lazy load anything). Of course, commands can be overloaded to fetch more or less, so you can implement them exactly for your needs, but a reasonable standard would be a cool thing.

      The current version in CVS reflects the standard we need in our Swing applications...

      Comments are welcome!

      a few commands are still in the pipeline, I will commit them after testing a bit more. But the next week I have very limited time for jbpm development :-(

      Regards
      Bernd

        • 1. Re: Some Commands committed
          Tom Baeyens Master

          thanks. great news.

          the depth of the object graph is indeed what still needs to be discussed. i think i have posted already some ideas before on this dev forum.

          probably the most easy solution is to just resolve the minimal graph (only using hibernate's lazy loading) and then using inheritence for expanding this graph as needed. if a user wants a more deeply resolved objectgraph, he/she can just subclass the original command and add navigation to activate lazy initialization.

          what do you think ?

          regards, tom.

          • 2. Re: Some Commands committed
            Bernd Ruecker Master

             


            probably the most easy solution is to just resolve the minimal graph


            The question is: What is the minimal graph? If I only return a ProcessInstance for example, I even do not have the root token! So I think, thats not a real valuable graph for the client.

            Subclussing is indeed a good solution, but to have a subclass for each and every use case is not so nice. So I think we need a tradeoff between performance and "usability".

            What do you think about the current pre-fetching (you can look at it in one class: AbstractGetObjectBaseCommand), too deep?