1 2 Previous Next 21 Replies Latest reply on Feb 2, 2008 2:34 PM by Ronald van Kuijk

    including graphical information in the process definition

    Tom Baeyens Master

      we started an email thread on configurability in the designer of the variable expressions. soon it ended in an interesting ever-returning discussion about wether the graphical information should be included in the process definition. how the link was established between those two will remain in the secrets of history, only to be discovered by IT-archeologists that still have to be born :-)

      first david suggested namespaces in the process definition to distinct between different types of information like this:

      "david" wrote:
      Here's an idea - what about having just one XML file and use namespaces
      to disambiguate the different data? This could allow users to add their
      own extensions as well.

      Here's a mocked up example, modeled on the "simple" process:

      <process-definition
       xmlns="urn:jbpm.org:jpdl-3.2"
       xmlns:gpd="urn:jbpm.org:jpdl-gpd-3.2"
       name="simple">
       <gpd:diagram width="469" height="439"/>
       <start-state name="start">
       <gpd:node x="150" y="25" width="140" height="40"/>
       <transition name="to_state" to="first">
       <action name="action" class="com.sample.action.MessageActionHandler">
       <message>Going to the first state!</message>
       </action>
       </transition>
       </start-state>
       <state name="first">
       <gpd:node x="150" y="125" width="140" height="40"/>
       <transition name="to_end" to="end">
       <action name="action" class="com.sample.action.MessageActionHandler">
       <message>About to finish!</message>
       </action>
       </transition>
       </state>
       <end-state name="end">
       <gpd:node x="150" y="225" width="140" height="40"/>
       </end-state>
      </process-definition>


      to which i replied that imo, use of namespaces is not enough known in the developer community. so developers will probably mess up some times and then have to spend time on finding the problem with namespace, which they don't even understand.

      then koen replied

      Yes we have been discussing/thinking about this for a long time already.
      There are advantages and disadvantages in both approaches. What about the
      bendpoints for instance? Or the coloring of the node? Do you want to end up
      with xml like:

      <process-definition
       xmlns="urn:jbpm.org:jpdl-3.2"
       xmlns:gpd="urn:jbpm.org:jpdl-gpd-3.2"
       name="simple">
       <gpd:diagram width="469" height="439"/>
       <start-state name="start">
       <gpd:node x="150" y="25" width="140" height="40">
       <gpd:color>
       <gpd:gradient start="234,124,234" end="232,133,234"/>
       </gpd:color>
       </gpd:node>
       <transition name="to_state" to="first">
       <gpd:edge>
       <gpd:bendpoint x="23" y="45"/>
       <gpd:bendpoint x="34" y="23"/>
       <gpd:bendpoint x="45" y="43"/>
       <gpd:bendpoint x="56" y="26"/>
       <gpd:bendpoint x="23" y="12"/>
       <gpd:edge>
       <gpd:annotation>
       This transition should be reviewed because
       the bendpoints are badly chosen.
       </gpd:annotation>
       <action name="action"
      class="com.sample.action.MessageActionHandler">
       <message>Going to the first state!</message>
       </action>
       </transition>
       </start-state>
       <state name="first">
       <gpd:node x="150" y="125" width="140" height="40"/>
       <transition name="to_end" to="end">
       <action name="action"
      class="com.sample.action.MessageActionHandler">
       <message>About to finish!</message>
       </action>
       </transition>
       </state>
       <end-state name="end">
       <gpd:node x="150" y="225" width="140" height="40"/>
       </end-state>
       </process-definition>
      

      I have only modified the start state, but I think you can see my point.

      We should probably be (re-)discussing this on the forum btw...


      to which i now reply: good idea square. both on the suggestion for putting the discussion on the forum as well as mixing graphical information with the process.

      Agreed, the graphical information confuscates the structure of the process a bit. But the alternative is that this information is managed in 2 distinct files. In that case, users start making directories per process and they can still can mess up by loosing one of the two files when moving things around. Also, if the developer starts to mess in one file, how will the tooling get the other file back in sync ?

      Same situation is there for the links between tasks and forms.

      I think 1 file is best. I'm just in doubt wether it is more interesting to have 2 sections, separating the graph structure from the graphical information. or wether the graphical information should be really embedded in the graph structure itself.

        • 1. Re: including graphical information in the process definitio
          Ronald van Kuijk Master

          +1 for everything in one file (except the forms themselves)

          Sure it blurs the file to have namespaces, but creating 2 section introduces imo more complexity than it solves. Besides, learning namespaces is easy

          Maybe using namespaced attributes like e.g.

          <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"/>
           <state name="first" gpd:x="150" gpd:y="125" gpd:width="140" gpd:height="40"/>
           <transition name="to_end" to="end">
           <action name="action" class="com.sample.action.MessageActionHandler">
           <message>About to finish!</message>
           </action>
           </transition>
           </state>
          </process-definition>
          


          is easier to read

          Colors etc are a different thing... should they be included at all or configurable on a higher level e.g. in the gpd, not de pd.

          Maybe there it is an option to show/hide the gpd namespaced attributes when editing the source

          • 2. Re: including graphical information in the process definitio
            Bernd Ruecker Master

            It's difficult to decide that issue I think.

            On the one hand, I would be glad to have it one file. We do some XSLT-Transformation on the processes, for example to generate a processs documentation website, using a imagemap on the process. There it is very unhandy to have 2 different files and it would be cool to have only one file.

            Also I think is easier to keep everything in sync, if we have it in one file (for example renaming a node without using Eclipse-Plugin: You must also change the node name in the gpd.xml).

            But on the other hand, I like the very straightforward process definitions, because I often work directly in the XML. Too much informations about diagram would be really discuting there. I like the example from Koen, with all the bendpoints inside the diagram. That is not nice for modelling the process.


            So maybe I will vote for 1 file, with the most important informations (x,y of a node) in the section of the process definition and more "unimportant" additional stuff (like bending points of a transition) in a second section.


            One additional question from me: Whats then your oppinion, where to put other additional stuff (user gui form mapping, maybe some additional business variables like cost per task, ...)? Also inside that XML? Or make a own section for everything?

            By the way: How is that problem solved in other engines?

            • 3. Re: including graphical information in the process definitio
              Ronald van Kuijk Master

              wfmopen, an engine I looked at before/while choosing jBPM extentds xpdl by using namespaces. They do restrict themselves to functional information like variables, form info (they use xforms), "actionhandlers"

              Bendpoints will only be in transitions. They are often not that complex and the additional info will not disturb to much I think(well, hope) and color info should be kept to a real minimum (imo), mayby it should even be in a css file ;-) (just kidding). Personally I would not go for doing things two different ways (so no separate section for e.g. bendpoints. Maybe

               <transition name="to_state" to="first">
               <gpd:edge>
               <gpd:bendpoint x="23" y="45"/>
               <gpd:bendpoint x="34" y="23"/>
               <gpd:bendpoint x="45" y="43"/>
               <gpd:bendpoint x="56" y="26"/>
               <gpd:bendpoint x="23" y="12"/>
               </gpd:edge>
               </transition>
              


              could be rewritten as

               <transition name="to_state" to="first" gpd:poly="23,34,11,-22,11,20,11,-17,-33,-14"
               </transition>
              


              But that could be totally incompatible with EMF,GEF or whatever eclipse framework is used.



              • 4. Re: including graphical information in the process definitio
                David Lloyd Master

                Ah, namespaced attributes - a great idea, I never even thought of it. However I'm not a big fan of squeezing many data items into a single attribute. I think that for multiple data items we'd still need separate attributes.

                But I could totally see something like this (note that I put <gpd:bendpoint> right within - there's no need to add another level of nesting that I can see):

                <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">
                .... and so on ....
                


                I don't think separate sections are a good idea. This is XML, I mean we're not talking rocket science here.

                In addition, forms.xml could (and should, in my opinion) be merged in - the form declarations can go right with the task node declarations. If it were me I'd even merge in the task forms themselves (they are XHTML after all), though I think that might be pushing the limits of popular acceptance. :-)


                • 5. Re: including graphical information in the process definitio
                  Ronald van Kuijk Master

                  wfmopen does embed the taskforms in the definition. I personally would (in this case) not do that. The .xhtml files can be edited by the upcomming RHDS (or one of it's separate modules) if they are separate files. This will not be possible if they are embedded.

                  Regarding the 'squeezing', I'm not a big fan of that
                  either. It was just a wild proposal. otoh, leaving the 'gpd:edge' in could make it easier for Koen to process it (although I might be totally wrong, since I do not know the internals of the gpd, let alone the eclipse frameworks.

                  • 6. Re: including graphical information in the process definitio
                    David Lloyd Master

                    Good point about the editing with a separate editor - from a programmatic perspective embedding the task forms is better, but from a user perspective it would probably just be a pain in the ass.

                    As far as the separate element goes though, I think it's just as easy (or easier) to parse without it - the GPD (or anyone else) need simply iterate the child elements of the "transition" element, as opposed to finding a child of "transition" called "edge" in the GPD namespace, and iterating the child elements of that. I'd say it's even easier this way. With DOM it's less traversal, and with SAX or StAX it would result in a simpler state machine.

                    • 7. Re: including graphical information in the process definitio
                      Ronald van Kuijk Master

                      I agree with the dom/sax/stax argument, but I did not know if eclipse had some automagical mapping hence my reserve.

                      Also I think from a versioning perspective, the forms should be separate. When a new form is generated the old/previous one should be renamed and a warning given. otoh, doesn't eclipse already have some local versioning?

                      btw, David, it is weekend and a kind of independance day here. On liberation day, may 5th 1945, WWII officially ended in the Netherlands. So let's not 'work' anymore, but party..... :-)

                      • 8. Re: including graphical information in the process definitio
                        Bernd Ruecker Master

                        Just to add a argument to merge in the forms.xml:

                        If the process-definition.xml is saved for any ProcessDefinition (I remember, there were plans for that?), a gui framework can easyly load the XML with the form mappings from the process definition of the right version for every running process. That would be a good step towards supporting really different process versions.

                        Mixing in the forms sound really horrible for me. Okay, I am not the Web-Gui-Fan, but even then, some seperation of concern should be kept!

                        Hope, it was a good party Ronald? Germany has only rain these days :-(

                        • 9. Re: including graphical information in the process definitio
                          Jeff DeLong Master

                          The current version of the designer requires the user to be very familar with jpdl and hand edit the file. In this situation it would not be good if there was graphical information contained in the file as well. With the next release of the designer, there should be much less hand editing required, and in the future this should get even better. So post designer 3.1 combining graphical information in the same file as the jpdl should be manageable, and would have the benefits that have been mentioned in other posts. I would not want to see the forms information in the same file however.

                          • 10. Re: including graphical information in the process definitio
                            Ronald van Kuijk Master

                            First some 'official comments'

                            It sounds we all agree (I know Gavin was not fond of integrating all this, but afaik, he wants to include pages.xml info into the .xhtml pages, so effectively he is doing the same)

                            I tend to disagree with Jeff however that we should limit ourselves because currently a lot of hand-editing is needed. Otoh, I do think it is not realistic to expect this to be in the 3.1 designer, mainly because it also requires a new version of the core and webconsole.

                            So lets target 3.2 of the designer (or whatever version Koen has in mind) and 4.0 of jBPM

                            Bernd,

                            The party is less and less about the end of WWII but more and more about anti-discrimination, anti-racism etc, which I think is good. So it is not so much a real celebration anymore. Queensday however is much better and a real 'must experience' for tourists.

                            Oh and about the weather, there is a new record for the longest period without rain now: 43 days. Farmers complain (don't they always), the nature conservationists complain (don't they always) but the normal people do NOT complain (as opposed to what they usually do about the weather)

                            • 11. Re: including graphical information in the process definitio
                              Edward Staub Expert

                              The graphical design view tends to hide some really important information in properties within nodes. So it's important to have a way to concisely view the semantic jPDL. Currently, all we have for that is the XML itself.

                              If the editor provided an XML view that filtered out the graphical info, I'd be for 1 file + 1 section + namespaces.

                              Otherwise, I think 1 file + 2 sections is the way to go. It's not too important, but I'd put a namespace on the graphical info regardless.

                              -Ed Staub

                              • 12. Re: including graphical information in the process definitio
                                David Lloyd Master

                                I disagree - it's XML, and XML doesn't exist for human consumption. Once you go down that road, you start to cripple the format more and more and pretty soon it's hardly usable or at the very least, overly complex to parse.

                                If you're using the GPD, then you shouldn't need to hand-edit the XML anyway. If you aren't using the GPD, then you won't have GPD data to worry about in the first place. And personally I don't find it at all confusing to mix that information as illustrated above - using Facelets you do that all the time, sometimes with as many as 10 or more namespaces. It's as readable as XML gets (which is not very, unless you're accustomed to it).

                                • 13. Re: including graphical information in the process definitio
                                  Edward Staub Expert

                                  David,

                                  I disagree - it's XML, and XML doesn't exist for human consumption.


                                  Ideally true, but in practice, there's currently no alternative to reading the XML if you need to see both the big picture and some details at the same time.

                                  A good example might be to consider the case where you're reading a process definition and want to understand the data flow through the process variables. Do you want to click on every node to see where each variable is used? How much longer would that take than searching the XML? Would you be willing to do two or three passes, looking for different details each time, as you might if you were searching the XML? If you had to open a dialog box for every node, how would your memory retention compare with doing a search through the XML?

                                  I think it will be at least two years, if ever, before GPD is at a level where reading the XML isn't really necessary.

                                  If you're using the GPD, then you shouldn't need to hand-edit the XML anyway.

                                  Agreed, assuming the usability is good in all cases. But my concern is about reading, not writing. By way of analogy, imagine if you were using some UML-based code editor, and the only way it allowed you to see the source file was in a very modal fashion. You could navigate to a method and open it, but you couldn't scroll through the source. What would this do to your ability to see the big picture? If you ever tried VisualAge For Java, you've seen this.

                                  I don't find it at all confusing to mix that information as illustrated above - using Facelets you do that all the time, sometimes with as many as 10 or more namespaces.


                                  Given the overall goals of the project, I think the bar probably should be higher than "not confusing". The current schema is about as easy to read as it could possible be, and I think that, if possible, it should stay that way until GPD is far more advanced than it is now.

                                  -Ed Staub


                                  • 14. Re: including graphical information in the process definitio
                                    Koen Aers Master

                                    Well, finally a reaction from me...

                                    Sorry guys, I was strolling around in Yosemite National Park this weekend and had to go to the San Francisco Giants - New York Mets baseball game with the JBoss marketing girls yesterday evening ;-))

                                    So it seems that everyone agrees... except for me...

                                    I definitely see the value of keeping the information in one file. And if that is the way to go, I would strongly opt for a separate section with graphical information. I gave the example with the different bendpoint tags and with the coloring information but the problem stretches further than that. It could e.g. contain a textual note graphical element that is completely unrelated to any of the jpdl constructs, but has only a relationship with the graphical information. All in all it boils down to the fact that some of the graphical information is not related at all to the business infromation and the other way round. So keeping the information in two separate sections seems appropriate to me. Whatever you may think and how good the tool in the future may become, the processdefinition.xml file will be read by humans, so we should make this not too difficult.

                                    Regards,
                                    Koen

                                    1 2 Previous Next