-
15. Re: Potential enhancement to jbpm
alternatively users should be able to write their own parsers to extract the information from a process archive and put that information somewhere in the process definition.
While cutomizing the core jBPM libraries and data model is always an option for virtually any problem, its never the preferred solution for common problems. --the more frequently users must solve common problems in this way, the more likely they are to look elsewhere or to fork the project.In jPDL 4 i want to add annotations. Basically, annotations are key-value pairs that you can associate to all process elements.
This does allow the user to solve the problem much more easily, and is a big improvement over what we have now. However, it falls short of providing a standard solution to the nearly universal problem of declaring an interface requirement. It's also not an option till version 4. :-)
Allowing the user a way to solve this problem is just a start, but providing a common solution is what is really needed. The user shouldn't have to look at an attribute tag and then invent a way to use it. At least for this particular problem which is such a common requirement, the jpdl should acknowledge the issue and provide the solution. At the same time, the jpdl should only solve it from the process definition side--in a way that does not tie the definition to a display technology.
The basic solution I presented earlier in the thread does all these things. The solution:
1) presents users with a common, defined jpdl solution for associating elements with UI requirements.
2) is not specific to any display technology, whether it be Swing, JSF, or any other tech that comes along.
3) does not require any knowledge of the display technology. So the display technology can be changed on top of existing definitions without impact.
4) can be added to jBPM 3.3 with minimal effort.
5) could likely be used in the jbpm web module to support robust UI versioning with minimal effort.
Items 2 and 3 are true so long as the user uses a reference to a UI requirement, rather than an actual view id; however, there is nothing stopping them from supplying a view id and using it directly if they don't mind tying the definition to their display technology. -
16. Re: Potential enhancement to jbpm
I've created Jira issues for these four pieces of data:
task ui= http://jira.jboss.com/jira/browse/JBPM-1149
process-definition ui= http://jira.jboss.com/jira/browse/JBPM-1150
process-definition release= http://jira.jboss.com/jira/browse/JBPM-1151
process-definition timestamp http://jira.jboss.com/jira/browse/JBPM-1152
If someone is willing to implement the ui= attributes, I'll provide a section for the documentation that describes their purpose and provides a good usage example--just tell me who to send it to. -
17. Re: Potential enhancement to jbpm
We are locally looking into adding something like a release number. Two things:
- 1.2.14 as an example is difficult, as a string to decide which is newer
- the processdefinition in the DB already has a long as version, couldn't we use that and do someting like MaMiBu where Ma is two positions for the major release Mi is two positions for minor release, Bu is two positions for a 'build'. 10412 being 1.4.12 and 212301 21.23.01.
This would be implementable now since it only needs a xsd change and some method changes, no db change
btw, Tom, I hate annotations in an attribute-value pair kind of way.... yuck... just to be able to add custom attiributes? -
18. Re: Potential enhancement to jbpm
Ronald,
Of course, you would have to implement code to reject re-deployment of a process definition that tried to deploy with a version number that was already in use for that definition name, but other scenarios would require some thought--would you stop deployment of a definition just because its version number is lower than the greatest currently deployed version? (someone might intentionally want to re-deploy and use an earlier release. Then, how would jBPM know that the earlier release number is the definition it should be using?)
Personally, I think its cleaner, safer, and more flexible to just let jBPM continue managing the version_ field itself, and give the developer a separate field to version their process definition's content.
I suppose we're really talking about two different things: the jBPM version_ field is versioning deployments, whereas the developer is versioning content. -
19. Re: Potential enhancement to jbpm
"kukeltje" wrote:
btw, Tom, I hate annotations in an attribute-value pair kind of way.... yuck... just to be able to add custom attiributes?
the annotations are only a way to make it extensible.
all the attributes that we know about can be supported in the schema directly. e.g. <task ... form="my-task-form.xhtml"...>
some of the directly supported attributes that are infrequently used, may be mapped to the generic properties (was annotations) in the db. -
20. Re: Potential enhancement to jbpm
"brittm" wrote:
Of course, you would have to implement code to reject re-deployment of a process definition that tried to deploy with a version number that was already in use for that definition name,
or even more strickt: the given version number has to match exactly with the expected version number, which is the previous highest version + 1
the motivation for this is auto deployment. if we have such a mechanism, then you can drop your processes in a deploy folder. a deployer can then figure out if the process needs to be redeployed or not.
it also keeps the developer in charge of whether he wants to redeploy or not. the designer tool could offer convenience for this by incrementing the version in the source file automatically each time when you deploy.
i'm still not totally clear on how to deal with multiple staging environments. where you want to just deploy like we do now in development, but you want the verified deployment in production.
a potential solution might be the deployment interceptors that i've just worked out. (a more generic variant of the configurable parser sequence that we have now in jbpm 3). i have one interceptor that does the validation and that one is configured in the configuration file. so if in development you don't want that validation, then you just remove that line in the environment configuration.
anyways, all these are many ideas that didn't result into a clean picture for me. so all input like this is certainly welcome."brittm" wrote:
I suppose we're really talking about two different things: the jBPM version_ field is versioning deployments, whereas the developer is versioning content.
those two are related. and it's infact that relation that is not always clear.
britt, can you ping me in another email. i tried to email you and i got a failure on your account. -
21. Re: Potential enhancement to jbpm
the annotations are only a way to make it extensible.
No, I disagree. I implemented (a long time ago) some code in jbpm (my local branch) that you could use to extend process files with your own tags, just in a different NAMESPACE (I know you hate those, but I hate attribute value solutions MUCH MORE ;-)). Remarks like: namespaces are difficult are rubbish. I could draw up some small examples that anybody could understand (even my manager did) but the decision is up to the you guys.... I'll concede with whatever comes out... -
22. Re: Potential enhancement to jbpm
FWLIW, I'm with Ronald - namespaces.
Talking about WS-* use of namespaces reminds me of a lead developer I knew, who forbade the use of XML for anything, even simple config files. It turned out that he had been on a project that embedded large audio streams in XML, then used a DOM parser to read them. You can picture the issues that ensued... "why does it take a minute to start playing?" That convinced him that XML is EVIL. -
23. Re: Potential enhancement to jbpm
"kukeltje" wrote:
the annotations are only a way to make it extensible.
No, I disagree. I implemented (a long time ago) some code in jbpm (my local branch) that you could use to extend process files with your own tags, just in a different NAMESPACE (I know you hate those, but I hate attribute value solutions MUCH MORE ;-)). Remarks like: namespaces are difficult are rubbish. I could draw up some small examples that anybody could understand (even my manager did) but the decision is up to the you guys.... I'll concede with whatever comes out...
properties and namespaces don't exclude each other.
in fact, i don't have anything against namespaces. i just want that it is also possible without. since i don't have the time to work out the solution with and without namespaces, i opt to build the solutions without namespaces first.
if someone would contribute proper namespace handling (so that it still works without), that would be great. only if a decent test suite is worked out, this can be maintained.
for a start, i know that the dom parser that we have in pvm supports namespaces.
so go for it :-) -
24. Re: Potential enhancement to jbpm
the second thing I hate most (besides AV-pair solutions) is having 2 different solutions for the same problem... twice the amount of documentation, twice the amount of errors, twice the amount of questions, twice.... DRY...
I'll have my first look at the jdpl parsing for 4.0 (if there already is something in cvs) and see what can be done. The only thing *I* need is access to the stored xml in whatever form. The api will be very simple and very dom/xpath like... clean and simple just need the xsd to allow any content with *other* namespaces below any element