4:35 a.m.
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
anonymous wrote :
| 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.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043424#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...