1 2 Previous Next 21 Replies Latest reply on Feb 2, 2008 2:34 PM by kukeltje Go to original post
      • 15. Re: including graphical information in the process definitio
        kukeltje

        I miss one thing: what is the advantage of one file with two sections over two files? (assuming we still want to merge the forms.xml into the processdefinition.xml)

        And if there are some gpd namespaced elements that have no relation to any process construct (besides the processdefinition at the highest level) I see no problem puting them separately, but having the processconstruct related gpd elements in there would not be a problem imo. So something like

        <process-definition
         xmlns="urn:jbpm.org:jpdl-3.2"
         xmlns:gpd="urn:jbpm.org:jpdl-gpd-3.2"
         name="simple"
         gpd:width="469" gpd:height="439">
         <start-state name="start" gpd:x="150" gpd:y="25" gpd:width="140" gpd:height="40">
         <transition name="to_state" to="first">
         <gpd:bendpoint x="23" y="45"/>
         <gpd:bendpoint x="45" y="67"/>
         <gpd:bendpoint x="22" y="11"/>
         <action name="action" class="com.sample.action.MessageActionHandler">
         <message>Going to the first state!</message>
         </action>
         </transition>
         </start-state>
         <state name="first" gpd:x="150" gpd:y="125" gpd:width="140" gpd:height="40">
         <transition name="to_end" to="end">
         </state>
         <gpd:note>
        Just a not in a separate element, but no section
         </gpd:note>
        </process-definition>
        


        Or do you mean colorinfo etc??? instead of notes? Still then, putting that in a separate element and refering to it is not a problem imo.

        Or do I miss something?

        • 16. Re: including graphical information in the process definitio

           

          what is the advantage of one file with two sections over two files?


          Atomicity. They can't get skewed. I've seen GPD bugs where one gets mucked up, the other doesn't. If someone needs to move a definition from one place to another, it's easier. If they want to version a definition (e.g., in a source-control system, or by copying and renaming the file(s)) it's more obvious.

          -Ed Staub

          • 17. Re: including graphical information in the process definitio
            kukeltje

            Yes, that is true if gpd info is a e.g. a child of a processelement, not if it is in a different section in the xml. You still need to maintain/update the relations then just like with two files. (or maybe I have a completely wrong perception of the term sections)

            Regarding the versioning, you are right, but there the issue still remains for the forms pages, classes etc.... so I always make sure I version everything in a process.

            • 18. Re: including graphical information in the process definitio

              Ronald,

              Yes, that is true if gpd info is a e.g. a child of a processelement, not if it is in a different section in the xml. You still need to maintain/update the relations then just like with two files. (or maybe I have a completely wrong perception of the term sections)


              I think we mean the same thing by section. If they're in the same file, a bug in GPD could get them skewed, but very few external events or conditions can. Think of it like a record in a database. You COULD forget to update a field, but in general if you update everything in one statement, you can be confident you won't only get only half of it on disk. (I'm ignoring transactions.)

              My thinking is badly colored by a recent bug in GPD where, if I remember correctly, it would write a 0-length gpd.xml. Getting all of your nodes dumped in a heap in the corner of the "room" (canvas) was just plain rude!

              -Ed

              • 19. Re: including graphical information in the process definitio
                tom.baeyens

                So I think most of us agree here. One file with a separate section for the graphical information.

                The GPD will then keep the structural (readable) process information in sync with the graphical view. But the graphical information will not be syned. Preferrably, the graphical information will be folded in the XML view. When the process definition file is saved, the graphical information is overwritten.

                • 20. Re: including graphical information in the process definitio
                  simonbaker

                  Has this change taken place in some version or been scheduled to take place? We're still working with two separate files.

                  • 21. Re: including graphical information in the process definitio
                    kukeltje

                    no, it has not. I just filed a jira issue to keep it on the radar

                    1 2 Previous Next