It's all about the answers!

Ask a question

Calculating derived attributes using java instead of Javascript

Amaury Quintero (901017) | asked Nov 05 '13, 3:44 a.m.
Hello everybody

It is possible to use Java code inside advisors to calculated derived attributes instead of javascript? If I put the code in Participants then, the workItem was already saved and you have to save it again, but it is possible to modify workitemNew with your own modifications to save? Thanks

Accepted answer

permanent link
Ralph Schoon (61.1k33643) | answered Nov 05 '13, 4:43 a.m.
edited Nov 05 '13, 4:43 a.m.
Hi Amaury,

you can use Java to do things like that. You can not use an Advisor if you want to modify the element that triggers the save. An advisor should advise and not modify anyway. You need to do it in a participant, if you want to update the work item that triggered the action. See as an example that updates a parent. However, you could also update the triggering element in the participant as shows.

You can also create a Java Extension as value provider instead of JavaScript that shows up in the Attribute Customization section, as described here:

The limitation of providers is, the return value only works for the attribute it is configured for.
Amaury Quintero selected this answer as the correct answer

One other answer

permanent link
Amaury Quintero (901017) | answered Nov 05 '13, 5:34 a.m.
 Thanks for your answer Ralph, 

I did exactly the same you propposed in your excelente review

That works, but in that case you save the current workItem twice and I was looking to avoid the 2 saves operation for performance reasons, if you dig into the workitem history, you can tell the 2 operations 



Ralph Schoon commented Nov 05 '13, 5:53 a.m.

Hi Amaury, if you want to avoid the second safe, you would have to use a java Based provider. Some examples are here: You would basically calculate the value in Java instead of JavaScript. It is harder to deploy, because you will have to deploy it on client and server. The follow up action works for all clients and also if you use the API, whereas the provider only work for the Web UI and the Eclipse client if the providers are deployed. JavaScript would avoid deploying, but would also not work with Visual Studio or API calls.

Amaury Quintero commented Nov 05 '13, 6:35 a.m. | edited Nov 14 '13, 12:50 p.m.

Thank you very much Ralph

It is a good solution, but I think in terms of simplicity, I prefer the previous one (two saves) because in our case we need to update more than one attribute at the same time, depending on other values, the we would need to create one Provider for each one (too much work) and beside that the logic will be split in 2 parts, (not good for maintenance purposes)

the second approach wiil work for other purpose and I wiil start to use that way, thank you!!

Your answer

Register or to post your answer.