topic Re: How to access fields in java service task in Alfresco Archive

How to access fields in java service task

sk8192 — Mon, 12 Nov 2012 23:03:57 GMT

If I have the following task definition: <serviceTask id="myServiceTask" name="My Service" activiti:expression="#{myService.myMethod(execution)}" activiti:resultVariableName="result"> <extensionElements> <activiti:field name="testField"> <activiti:string&

Re: How to access fields in java service task

ronald_van_kuij — Tue, 13 Nov 2012 18:24:56 GMT

You can't afaik when using expressions… Put the 'field' as a param in the extression and it will be passed in you method.

Re: How to access fields in java service task

sk8192 — Wed, 14 Nov 2012 16:08:18 GMT

That's what I was afraid of. Oh well.

Thanks, Ronald.

Re: How to access fields in java service task

frederikherema1 — Fri, 16 Nov 2012 10:40:55 GMT

Ronald is right, you can't use field-injection on activiti:expression (since the expression resolves to a method-call and NOT a callable object.

Can't you just pass in the arguments you want in the method-call expression itself?

Re: How to access fields in java service task

ronald_van_kuij — Fri, 16 Nov 2012 12:01:46 GMT

Frederik,

That is what I mentioned as well, but internally we got the feedback that this is 'less intuitive' for the some people in the designer. But having the designer construct an expression based on 'fields' where fields are put in the method call in the order they are in would help a little, but the business people still would need to know the order of the parameters… This limits the use of custom components in the designer drastically… (unfortunately)

Re: How to access fields in java service task

frederikherema1 — Fri, 16 Nov 2012 12:41:01 GMT

As the activiti:expression functionality requires knowledge of the context of the application and it's beans/methods, I don't see an immediate use for Business-analysts. If people (devs) want to offer well-know building-blocks for analysts/other people to use, I see these solutions:
- Using a JavaDelegate with field Injection (which in turn, can delegate to one or more bean/method-calls hiding complexity) OR
- A custom designer-extension (with the correct form on it, which generates a delegate-method call with correct parameters) more feasible.

So creating a method-call at design-time based on fields seems to be a very exotic use case and error-prone, imho. Nevertheless, it's indeed confusing that you can combine fields with activiti:expression and activiti:delegateExpression and ideally the "fields" should disappear from the UI in these cases