2 Replies Latest reply on Oct 19, 2007 4:48 AM by tom.baeyens

splitting access= on variables into multiple attributes

kukeltje Oct 18, 2007 3:46 PM

I know work is being done on WS-HumanTasks as a probable solution for the task configuration in the PVM. (133 pages... wow.....)

4.0 will not be out shortly, but I do see enhancements to the current UI that would be to difficult, while maintaining backwardscompatibility.

A variable is currently written as

<variable access="read,write,required" name="myVar"></variable>

Most web ui frameworks use something like

<variable readOnly="true" required="true" name="myVar"></variable>

The read is often not there, so it is not needed imo (if you cannot read it, you should not put it there)

This would make it possible to do things like

<variable readOnly="#{actorId=='Ronald'}" required="#{transition == 'GoLeft'}" name="myVar"></variable>

Or more complex ones... Conditionally requiring variables. This would greatly enhance the capabilities of the webconsole, doing even nicer things in RAD environments.

Ofcourse access= should still be supported, so I do *NOT* propose to ditch this, or write any converters.

Thoughts?

1. Re: splitting access= on variables into multiple attributes

kukeltje Oct 18, 2007 4:16 PM (in response to kukeltje)

And yes, I know this can all be done in the generated forms, but so can "access=read, write, required" so that will not be accepted as a reason for *no* ;-)
Actions
2. Re: splitting access= on variables into multiple attributes

tom.baeyens Oct 19, 2007 4:48 AM (in response to kukeltje)

in 4.0, for jPDL i hope to pursue the following:

1) jPDL in bacwards compatibility mode. old jPDL processes will be deployable in jPDL 4, but the databases will probably be incompatible.

2) jPDL 2. There are a lot of improvements that can be made to jPDL. More direct support for other concurrecy models, hierarchical sub-tasks instead of the flat list we have now, process annotations, static variables, variable declarations, etc

3) expand jPDL 2 with many functional node types. E.g. like the mail node we have now or with web service invocation nodes. also we might think of modelling external triggers. E.g. transactions might be external triggers or internal events. When those triggers are explicitely modelled with input parameters, it's possible to generate java beans or web services from that (like BPEL does).

This last focus would allow us to cover a big part of the BPEL functionality with free graph modelling, easier integration between services and java and other node types,...

But with out limited resources, we'll have to take it step by step and see where we end up...
Actions

Go to original post