Extension of schema and Task-objects

[sebastian.s]

Good evening,

I've got a question regarding schema extension. In JIRA and in the forums schema extension has already been discussed AFAIK it is planned to make the schema extensible in the future.

Assuming I would like to store information about tasks in an additional task-attribute I would be in need to add this new attribute to the schema definition for a task. But what about parsing and especially accessing this information during runtime? I would also be in need to extend the parser and the Task-class to make this information available at runtime, right?

Thanks for any comments on this.

Sebastian

[kukeltje]

When you add the attributes to existing nodes/elements and you need them to do something, yes. You need to extend the parser as well. In many cases just the activity binding and implementation, not the JpdlParser (afaik).

I personally would also opt for a nice api to retrieve additional attributes on existing elements (activities)

[kukeltje]

Oeps, wrong button....

..... where you do not need to customize the activity but do need access to the value to do something based on the value

[sebastian.s]

Hello Ronald,

thanks for your answer.

"Ronald" wrote:

I personally would also opt for a nice api to retrieve additional attributes on existing elements (activities)

I am especially interested in this, too: storing information with tasks and retrieving them later on so I would love to see something like this. IHMO opinion it's a common use case that you deal with a task list in your own application or client and you are in need of additional information what the task is about and how to represent and deal with it in your program. The possibility of having custom attributes in a convient way without the need of extending or implementing would make a thing like this a lot more easier.

For example: You could define use-case-specific task types because you know that in your processes you got 3 different kinds of users tasks, for example. So you could always determine the type of a task to display a proper form to input data or you react in a different way in your application.

I hope you get the idea of my example. I'd love to hear what you think about my thought.

Cheers!
Sebastian

[kukeltje]

This is indeed what I used something similar for in jBPM 3. It's not that difficult since you can retrieve the processdefinition in xml as a resource from the deployment and use xpath on it for retrieving the additional attributes.

What I did (amongs other things) was adding an attribute to a task with the average duration (different from the duedate). Without extending the database, I was able to use this.

Otoh, in jBPM 4 it is much easier to extend an activity then it was in jBPM 3 since there is no database model to be extended. Just extend the activity and change the activities xml config file and you are done. The two solutions can coexist without any problem, although I think the activities config file was more for new node types than extending existing ones.

[sebastian.s]

Hello Ronald!

Thanks for posting about your experience. I thought about it in a more general way without the need to change or extend distribution files. However it is good to know that this would work without problems.

Imagine the following task definition:

<task name="task1" .. >
 <attributes>
 <attribute name="tasktype" type="xs:string" value="simple"/>
 ..
 </attributes>
</task>

Of course the values wouldn't need to be writeable. I see it as a way to provide more information about a task but not a specific one but a specific type of task.

Does this make sense to you?

Sebastian

[kukeltje]

Does this make sense? Yes and no. I miss why this is more general then my adding attributes to the task element? IMO it is the same but adding a child element instead of an attribute.

[sebastian.s]

I guess I was a bit unclear. Instead of adding several attributes to the task element which would also need to be added to the class definition one could have one member-variable holding a set of Objects representing the additional attributes. So there would be no need to extend oder change something.

[kukeltje]

Ok, now I understand. But this feels to much like a 'hack'. Don't know why, just feels like something that could be abused. And you can already do these things with actionhandlers etc, so I would not extend this to the activities....

otoh... hmmm... I wonder what others think of this.

[sebastian.s]

Thanks for your answer, Ronald. Maybe you're right in this is too much a hack. The intention for this: I was thinking what happends if I extend Task and in a later release the same attribute name is introduced officially. That would need a lot of changing in your project if you desired updating to the new release.

[kukeltje]

Colliding attributes It would *not* happen if the attributes are namespace prefixed and you put yours in e.g. the mvg (met vriendelijke groeten) and jbpm uses well... jpdl e.g.

That is why I HATE the any:any extension.

:-)

[sebastian.s]

Agreed. I forgot about the namespaces but since Tom found his peace with namespaces this is a good solution. By the way I like mvg namespace and I will be in the Netherlands in November. :)

Met vriendelijke groeten

Sebastian

[kukeltje]

I will be in the Netherlands in November. :)

Wow, I'm impressed. From the Dom in downtown Aachen to the Dutch border it is 4,4km!!! :-P

[sebastian.s]

Being next door in Vaals is not really like being in the Netherlands. ;)

[kukeltje]

I have to agree. It's more like being in the eastern part of Belgium to so degree.

Only when one arrives in Utrecht, one can really say one is in the Netherlands.