-
2. Re: feature suggestion: add a description for transitions
camunda Oct 22, 2009 10:29 AM (in response to sebastian.s)Hmm, why do you need that "technical short name" and don't just use the name as business name (meaning the longer description")?
There is no real downside of it, or is it? Introducing a new attribute is not necessary here in my oppinion, but correct me if I am wrong or missing something.
Cheers
Bernd -
3. Re: feature suggestion: add a description for transitions
koen.aers Oct 22, 2009 10:34 AM (in response to sebastian.s)Are we back in the 'id' versus 'name' discussion? ;-)
Cheers,
Koen -
4. Re: feature suggestion: add a description for transitions
sebastian.s Oct 22, 2009 12:30 PM (in response to sebastian.s)Hi Bernd, hi Koen
I don't want to start over old discussions again but since I missed it what was the outcome of this diskussion? Was this the on about the question if task names should be unique or not?
Hmm, why do you need that "technical short name" and don't just use the name as business name (meaning the longer description")?
There is no real downside of it, or is it? Introducing a new attribute is not necessary here in my oppinion, but correct me if I am wrong or missing something.
From my point of view transition names should help business users understand the process.
When coding and using for example taskService.completeTask(taskId, outcome) I somehow don't feel comfortable to use this long name even with spaces since transition names need to be unique for one task so they name is a kind of identifier or even a signal name to take this specific transition.
Furthermore to facilate development of clients using the engine I would like to use a a kind of convention for transition names. For example after tasks which implement a user's decision which path to take in the process I'd prefer to give the same names to the transitions in different processes but a process specific description or long name for the transition. I hope I was able to point out my aspects.
cheers
Sebastian -
5. Re: feature suggestion: add a description for transitions
camunda Oct 26, 2009 11:14 AM (in response to sebastian.s)Okay, there may be some use cases. On the other hand I think you confuse people as well (what to use when). For the moment I don't feel it as a big problem.
If you talk about real business models (not for technical people) you face a lot of additional requirements not implemented in jbpm yet, so this is a different story.
So in summary I would leave it as it is or wait for enough people to show use cases, that it is really that important. -
6. Re: feature suggestion: add a description for transitions
sebastian.s Oct 27, 2009 6:06 AM (in response to sebastian.s)Thanks for giving your view on this, Bernd. There is no doubt that are still lots of additional requirements not implemented in jBPM yet.
However I don't see the point of confusing people. Because the way I described it seems quite clear to me:
There are transition names which are obligatory since they are used for the actual execution and there are description or long-names which are optional. Generating process diagrams shows the transition names unless descriptions / long names have been given. -
7. Re: feature suggestion: add a description for transitions
camunda Oct 27, 2009 8:22 AM (in response to sebastian.s)It may be clear for you, and even for people reading the docs... So for the others (the most people ;-)) it may get confusing, especially if the UI switches what it shows...
-
8. Re: feature suggestion: add a description for transitions
sebastian.s Oct 28, 2009 3:00 AM (in response to sebastian.s)You might be right, Bernd. But what about using a configuration setting which switches whether names or descriptions are shown? So the description could be completely optional.