-
15. Re: New console snapshot published, Task Forms included
Hey,
after playing around with this a bit, I stumbled upon 'outcome' being overwritten in the first execution of such a freemarker template, leaving any further attempts disfunctional.
I issued a bug about in jira:
https://jira.jboss.org/jira/browse/JBPM-2452
Does anyone have a quick workaround for this?
regards,
Marko -
16. Re: New console snapshot published, Task Forms included
Quick? From what I quickly tread in your jira issue, I'd say don't use outcome as a process variable? or do I miss something that makes even this not possible?
-
17. Re: New console snapshot published, Task Forms included
@ Marko
Good catch. Probably our task form examples have been too simple.
The use of "outcome" in both cases is misleading anyway. I'll take a look at it. -
18. Re: New console snapshot published, Task Forms included
@Ronald
or do I miss something that makes even this not possible
yes, you do. "outcome" turns into a process variable of that name, but at the same time triggers execution. It's a reserved name in that sense and shouldn't become a variable in subsequent activities. -
19. Re: New console snapshot published, Task Forms included
That it triggered the execution is indeed obvious, but I just figured that if you did not use it as a process variable (in any form), you should be safe. But from your statement I get that it does turn into a process variable automagically. Ok, never would have known that without analysing the source. Thanks for letting me know.
-
20. Re: New console snapshot published, Task Forms included
The problem is rendering of a form in a subsequent step. In that case "outcome" exists as a process variable, and will be injected into the freemarker rendering context and thus freemarker throws a parsing error.
-
21. Re: New console snapshot published, Task Forms included
OK, while the dynamic approach ain't working, I'll workaround by hardcoding the template options (it's a mockup, anyway, so the main aim is to get it working ASAP).
As far as suggesting a solution, I guess it depends on wether or not the outcome (as in: result of the action) is actually useful in subsequent process steps. If not, it probably should not be introduced into the process at all. I don't have sufficient insight into the ways of jBPM yet and therefore don't know about side-effects.
Another idea would be to have the default context stuff that you put into the form as an independent element/namespace 'ctx' or somesuch, containing everything that would go there (it would be nice, BTW, to have a list of the items one can use, I looked in vain for the activity name). 'ctx' should then be regarded as reserved in some way and not be taken from the process.
Or, maybe it would be even better to encapsulate the process variables in an element/namespace of their own, maybe named 'process'?
Just my 2 cent,
regards,
Marko -
22. Re: New console snapshot published, Task Forms included
Hi all,
I'm having the same error "Expected hash. outcome evaluated instead to freemarker.template.SimpleScalar" which results from a second pass on the same task form. From what is said I can't understand if there is a solution to this problem, I tried to delete the "outcome" variable from the process instance after the task is executed the first time, so the outcome variable shouldn't be injected into the freemarker, right? I need the outcome variable in the form to let me decide where the process flow is going.
Regards,
Sergio -
-