Adding layout info to the processdefinition file

[koen.aers]

We are seriously thinking of adding the layout info to the processdefinition file. The disadvantage of this is mixing the view info with the actual processdefinition, but there is a big advantage to it too : I have only one file to manage, this can be named whatever a user likes, there is no awkward *.par folder structure necessary, etc, etc.
In our opinion, these two kinds of info really belong together, though they may not always be relevant to the person authoring the processdefinition. So definitely they should, even within the same file, still be kind of separated, with maybe a possibility to hide/view.
Thoughts?

Regards,
Koen

[kukeltje]

A lot of thoughts, but the main one is:

+1

One additional thing, are you thinking of using namespacess to spearate the two?

Ronald

[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

[kukeltje]

different (more clear?) xsd's but that is just a hunch, not based on experience. How dos xpdl doe it?

[aguizar]

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.

[kukeltje]

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

[aguizar]

Man, that's serious. Hope you are getting better!

[tom.baeyens]

"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.

[gavin.king]

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.

[gavin.king]

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.

[tom.baeyens]

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.

[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.

[kukeltje]

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......

[gavin.king]

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.

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.

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.

[kukeltje]

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

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

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