Process definition element label attribute

[paolodt]

I'm a new to jBPM and it seems to be a great tool.

One of the most interesting feature is the Graphical Process Designer that permits to design and show a "business" view of the process workflow.

Anyway I think would be very useful to have "label" attribute as well as the "name" attribute for each process definition element (nodes, tasks, transitions, .. ).

In this way it would be possible to have a displayable name showed in the jBPM designer (for the business users / analysts interested to the graphical model diagram) and a element name to use as identifier in the application / workflow coding.


What do you think? Any plan to support that?

Thanks a lot, Paolo

[kukeltje]

There already is a description element which could be used for this if not filled in to 'prosaic'. Displaying it in the GPD is another story

[tom.baeyens]

this might actually make sense. currently, we use the name field for display, but that is also used as an id field.

the important thing is that the current approach of combining is and label in the 'name' attribute should be kept. but coming to think of it, nothing keeps us from adding a label attribute that is optional. the label returns the label or the name in case there is no specific label specified...

let me think some more. i think this might be a good idea.

[kukeltje]

Come on Tom.... Now I do not get you anymore... you opposed the addition of the variable type to the jdpl file so strongly and now in addition to a name, a mappedname and a description, a new label is added? Then please include the variable type as well, and now I come to think of it, why not include the coordinates as well (like xpdl)

The name is to be unique (like an id) is, on transitions used, for reference (like an idref) why not ditch the name/to then and realy use an ID and idref? the xsd standard can make sure these constraints are automatically met (a refid should point to an existing id, id's should be unique etc..etc..etc..ebBP uses this) Sorry if I sound a little frustrated (two STFF posts in 10 minutes) but I do mean what I say

[paolodt]

Nice Tom,

I was thinking exactly the mechanism you have described.

The descriptive label should be optional if not provided it would return the name value.

In this way it would be possible to have a more flexible process model presentation view, not tied to the elements name that should never change being identifiers used in the workflow application code.

In which version do you think it could be released?

Thanks, Paolo

[tom.baeyens]

"kukeltje" wrote:
Come on Tom.... Now I do not get you anymore... you opposed the addition of the variable type to the jdpl file so strongly and now in addition to a name, a mappedname and a description, a new label is added? Then please include the variable type as well, and now I come to think of it, why not include the coordinates as well (like xpdl)

there are a lot of things that i don't want.
* usage of the id attribute and an optional name attribute would be nice xml, but backwards incompatible
* forced label declaration separate from the id.

probably this was the spark that made me something that i do want : an optional extra attribute called label.

sorry if this is what you already proposed before.


As for the variable declarations, I have already changed my mind on that some time ago. I think it would be good to have it in, although, there is no need for it now, there are some extensions in the core engine that i want like variable initialization and type declaration. Both optional, of course.

Mostly, the variable declarations also can have there benefits for the GPD. So that the GPD can offer drop downs instead of text boxes for variables.

I don't treat this as a priority yet. Since there is no actual usage for it now. Also the way to use user-defined variable declaration data in e.g. forms has to be studied further for it to work in a general case.

"kukeltje" wrote:
The name is to be unique (like an id) is, on transitions used, for reference (like an idref) why not ditch the name/to then and realy use an ID and idref? the xsd standard can make sure these constraints are automatically met (a refid should point to an existing id, id's should be unique etc..etc..etc..ebBP uses this) Sorry if I sound a little frustrated (two STFF posts in 10 minutes) but I do mean what I say

in 4.0, i might consider want to switch to id and schema idref stuff. but that would become backwards incompatible... and needs a conversion utility. if the schema idref can be added to point to the name attribute, we could add it in our current schema (although we have to see how this works with superstates)

[kukeltje]

The variable declarations have their advantage in the GPD, but also in the webservice. It would be possible to generate xsd's with the correct types for setting variables in certain states/nodes/tasks. Now, there is not type checking other than manualy generating an XSD and using XSD validation.

Regarding the generation, seam form generation does a nice job. They are kind of similar to the jbpm forms. The FTL templates that are used use the type to generate correct input types, which is nice. Using FTL for the jBPM forms would be cool and in line with using similar frameworks for similar things across multiple jboss projects.

If I find time (lots of experimenting with seam now) I'll have a look at the id/ref stuff.