[estaub]

>> I would not abuse actionhandlers (that is what it seams to me ed)

Probably a fair assessment!

[brittm]

Namespaces seems like a good idea *if* jBPM could throw that part of the configuration into 'external config' tables with a foreign key to the jpdl parent element. I wouldn't care if the configuration were simply stored as a string--at least it would be trivial to retrieve in relation to the appropriate jpdl element. We're already doing this kind of thing with ActionHandler configuration.

Of course, we could do the same thing with a generic "meta" tag on the key jpdl elements.

One advantage to this approach could be that if we see people using this functionality to carry the same types of configuration over and over, then that usage could be a candidate for standardizing in the jpdl.

[kukeltje]

"brittm" wrote:
Namespaces seems like a good idea *if* jBPM could throw that part of the configuration into 'external config' tables with a foreign key to the jpdl parent element. I wouldn't care if the configuration were simply stored as a string--at least it would be trivial to retrieve in relation to the appropriate jpdl element. We're already doing this kind of thing with ActionHandler configuration.

Why the need for it to be in tables? Nodenames are unique, If you have the processdefinition in a dom, you van easily use an xpath statement to get to specific attributes of a specific node... no need to store it in a db. Just make sure in the processdefinition object that is in the hibernate cache, there also is a cached dom version of it... This could be implemented now without any changes to databases or whatever.

Of course, we could do the same thing with a generic "meta" tag on the key jpdl elements.

I hate 'generic' tags. They quickly become meaningless.

"brittm" wrote:

One advantage to this approach could be that if we see people using this functionality to carry the same types of configuration over and over, then that usage could be a candidate for standardizing in the jpdl.

Would we see people using it? Would they give feedback on how they use it? I doubt it.

[tom.baeyens]

"estaub" wrote:
>> I would not abuse actionhandlers (that is what it seams to me ed)

Probably a fair assessment!

yes, but it shows a clear need. we already planned to add configuration beans on process elementsin 4.0. that means that the process, nodes, transitions and such can be configured with wired objects.

those beans can then be used from inside action handlers or from external entities like a UI.

extra decoration information in plain POJO format

[kukeltje]

we should be aware that things do not get to complex... I myself sometimes have a hard time to keep up (maybe because I use jBPM to little hands on and spend to much time in the forum ;-))

[brittm]

Why the need for it to be in tables?

The point in using tables is consistency. To get configuration about a Transition, a user should expect to retrieve the transition and then retrieve the configuration off of it, just like they would for anything else.

I hate 'generic' tags. They quickly become meaningless.

Quite possible (on the meaningless part--I'm not qualified to comment on wether you like them or not :-) ). However, a 'meta' tag is no more meaningless than a note pad; its not the note pad that matters, its what you put in it, and that can only be as meaningless as you allow it to be. By giving developers a meta tag, we would in essence simply be giving them a place to jot down notes about their process elements (notes that they can access programatically later in the same way they access the jpdl elements themselves).

Would we see people using it? Would they give feedback on how they use it? I doubt it.

Well, we would use it. And I'm not shy about giving feedback. :-)

maybe because I use jBPM to little hands on and spend to much time in the forum ;-)

Unfortunately, I'm doing the opposite. Working with it too much and following the project too little.

[kukeltje]

Consistency should be in the api. It should hide the underlying implementation (be it DB or file or whatever).

Regarding the meaningless I apolologize. English is not my native language. What I meant to say was, anything can be put in it so it is clear most likely clear what is put in there, not what it is used for and where. So the usage (meaning) of it becomes unclear/fuzzy and therefore..... you get the point.

I hate feedback... oh... wait... no I don't..

[brittm]

Consistency should be in the api. It should hide the underlying implementation (be it DB or file or whatever).

Good clarification. Though I would suggest that jBPM developers might enjoy a consistent implementation as well.

Is there a reason that namespaces couldn't be stored in a 'user table' just as well? Something like *id,jpdlElementId,namespace,tagName,value*?

[kukeltje]

Yep, good suggestion. In some cases I do not see the 'added value' of storing it in the db, but it could be implemented that way (not before 3.3, since it requires db changes) We *could* implement it *now* with access to the xml file and change the implementation later on.

one question though... the jpldElementId is the internal id of a mapped xml element from the pd? What method would you suggest?

[brittm]

Perhaps something like .setGraphElement() / .getGraphElement() on the 'Notation' (or 'UserConfig' or whatever the object is)--that would cover ProcessDefinition, Node, Task, and Transition. At least at the moment, these four core items are the only places I can see a good use for the functionality.

So you might have variations like:

Notation notation = new Notation(GraphElement, namespace, tagName, tagValue);
...or...
Notation notation = new Notation();
notation.setGraphElement(Transition);
notation.setTagName(name);
notation.setTagValue(value);

[kukeltje]

and please file a jira issue for making this exception more clear

[kukeltje]

sorry, wrong topic, but it still is a good idea... (i'm currently working on this)