-
1. Re: Adding layout info to the processdefinition file
kukeltje Jan 11, 2006 5:40 AM (in response to koen.aers)A lot of thoughts, but the main one is:
+1
One additional thing, are you thinking of using namespacess to spearate the two?
Ronald -
2. Re: Adding layout info to the processdefinition file
koen.aers Jan 11, 2006 5:46 AM (in response to koen.aers)My feeling is that I should structure the graphical info (choose the right tags) in such a way that this is not necessary. Or do you see a particular reason to have different namespaces?
Regards,
Koen -
3. Re: Adding layout info to the processdefinition file
kukeltje Jan 11, 2006 8:35 AM (in response to koen.aers)different (more clear?) xsd's but that is just a hunch, not based on experience. How dos xpdl doe it?
-
4. Re: Adding layout info to the processdefinition file
aguizar Jan 11, 2006 3:42 PM (in response to koen.aers)XPDL does it with an element in the same namespace:
<Activity Id="12" Name="Check Data"> <Implementation> <Task> <TaskApplication Id="checkData"> <ActualParameters> <ActualParameter>orderInfo</ActualParameter> <ActualParameter>status</ActualParameter> </ActualParameters> </TaskApplication> </Task> </Implementation> <NodeGraphicsInfos> <NodeGraphicsInfo Page="1" LaneId="0" Width="75.0" Height="50.0" BorderColor="-16777216" FillColor="-1114150"> <Coordinates XCoordinate="228.0" YCoordinate="98.0"/> </NodeGraphicsInfo> </NodeGraphicsInfos> </Activity>
I stand by the idea of a different namespace for the graphic element, so that it looks like an extension to jPDL. -
5. Re: Adding layout info to the processdefinition file
kukeltje Jan 12, 2006 4:18 AM (in response to koen.aers)I agree, and sorry for not looking up 'how does xpdl do it' myself. I probably had a blackout due to a 39.1 (degrees celcius) fever
-
6. Re: Adding layout info to the processdefinition file
aguizar Jan 12, 2006 11:54 AM (in response to koen.aers)Man, that's serious. Hope you are getting better!
-
7. Re: Adding layout info to the processdefinition file
tom.baeyens Jan 18, 2006 6:00 AM (in response to koen.aers)"gavin" wrote:
I think it would be extremely ugly to see stuff about width and height of boxes in the same file as stuff that defines the business process.
These are *completely* different levels of abstraction! One is a description of the world. One is a description of a screen. Don't mix them.
Please at least leave the *option* to have it in a different file. -
8. Re: Adding layout info to the processdefinition file
gavin.king Jan 18, 2006 6:06 AM (in response to koen.aers)My view on this is that you are trying to mix together "model" and "view". The .gpd defines a view of the abstract model of the business process.
What you are trying to do here is equivalent to embedding HTML in Java business logic. It's even worse, in fact, since I never expect to edit the GPD by hand. I'm always going to use the tool for that. OTOH, I will rarely use the tool for editing the jPDL. Usually I will type that out.
I think the current CVS rev of GPD that I have been playing with does it Just Perfect by using:
foo.jpdl.xml
.gpd.foo.jpdl.xml
bar.jpdl.xml
.gpd.bar.jpdl.xml
This is just like the old convention for laying out Hibernate mapping documents next to the mapped classes. It's a good way. -
9. Re: Adding layout info to the processdefinition file
gavin.king Jan 18, 2006 6:07 AM (in response to koen.aers)By the way, I'm not per se against supporting an xmlns way of defining all in one file as an *option*. I just don't want to ever have to do this in my Seam examples.
-
10. Re: Adding layout info to the processdefinition file
tom.baeyens Jan 18, 2006 6:10 AM (in response to koen.aers)afaik, the only problem is that developers don't want to see the graphical information. and that is a matter of visualization. to accommodate that the gpd should fold the graphical information in the XML view so that it is not visible by default (even in the xml view)
the graph structure and the graph layout can't live without each other. so i think it is clumsy having to maintain a link between those 2 files.
imagine that word would store the text in one file and the style in another. how many times would users end up having only one of the 2 files or loosing the connection between the 2...
regards, tom. -
11. Re: Adding layout info to the processdefinition file
koen.aers Jan 18, 2006 6:11 AM (in response to koen.aers)Okay, then it is probably a good idea to keep things as they are for now and later add the option of having the graphical info in the same file. I will add this as a JIRA issue.
-
12. Re: Adding layout info to the processdefinition file
kukeltje Feb 2, 2006 12:58 PM (in response to koen.aers)"tom.baeyens@jboss.com" wrote:
imagine that word would store the text in one file and the style in another. how many times would users end up having only one of the 2 files or loosing the connection between the 2...
Ever looked at the fileformat of OpenOffice? Open it with winzip and be surprised....
I've heard the same is true for word as well...... -
13. Re: Adding layout info to the processdefinition file
gavin.king Feb 3, 2006 12:59 PM (in response to koen.aers)"tom.baeyens@jboss.com" wrote:
afaik, the only problem is that developers don't want to see the graphical information. and that is a matter of visualization. to accommodate that the gpd should fold the graphical information in the XML view so that it is not visible by default (even in the xml view)
But not everyone uses eclipse. And, inevitably, people need to edit things in plain text."tom.baeyens@jboss.com" wrote:
the graph structure and the graph layout can't live without each other. so i think it is clumsy having to maintain a link between those 2 files.
Sure they can. At deployment time, the layout is totally unnecessary."tom.baeyens@jboss.com" wrote:
imagine that word would store the text in one file and the style in another. how many times would users end up having only one of the 2 files or loosing the connection between the 2...
Well, arguably that would be a better architecture!
But actually, the analogy is broken, since Word users *never* work with the "source view" of the document. -
14. Re: Adding layout info to the processdefinition file
kukeltje Feb 3, 2006 2:03 PM (in response to koen.aers)"gavin.king@jboss.com" wrote:
But not everyone uses eclipse. And, inevitably, people need to edit things in plain text.
From what I've seen the embedding of the layout info does not make the processdefinition much less editable on the source level, but that is just mho"gavin.king@jboss.com" wrote:
"tom.baeyens@jboss.com" wrote:
the graph structure and the graph layout can't live without each other. so i think it is clumsy having to maintain a link between those 2 files.
Sure they can. At deployment time, the layout is totally unnecessary.
I disagree, the visualization of the processinstance uses this info do draw boxes around the states the tokens are in"gavin.king@jboss.com" wrote:
"tom.baeyens@jboss.com" wrote:
imagine that word would store the text in one file and the style in another. how many times would users end up having only one of the 2 files or loosing the connection between the 2...
Well, arguably that would be a better architecture!
But actually, the analogy is broken, since Word users *never* work with the "source view" of the document.
But often I wished I still could use F-12 to get rid of all this 'let me think for you' stuff of word (AKA 'WYSINWYW, what you see is not what you want)
OK, back to the discussion of using one file. I'm not a fan of mixing pageflow and workflow in one file. These are imo performed/designed/... by two different roles. Having them work on the same file, maybe messing up eachothers work is not what I look forward to. Currently a processflow in an engine (Yes not jBPM yet, but I'm convincing my superiours more and more) and a pageflow in JSF (and a faces-config.xml file) is what I currently use.
We are in the process of working out some kind of validator (offine, maybe later as an eclipse plugin, maybe even 'realtime') that matches the tasknames, transitionnames etc with actions in a faces config file. One task can consist of multiple pages. Works great