topic Re: Can we add 'hiddden' property in JavaTask in Alfresco Archive

Can we add 'hiddden' property in JavaTask

jjfutt — Fri, 16 Mar 2012 03:11:58 GMT

We'd like to know if we can add a hidden property in the interface definition of a JavaTask (when implementing custom JavaTasks for the palette), that are not available for the creators of itinerary/orchestration designers, but can be retrieved by the JavaDelegate implementation class. For example,

Re: Can we add 'hiddden' property in JavaTask

tiesebarrell — Mon, 19 Mar 2012 17:28:21 GMT

Hi,

no, there's no way to do that at the moment if you mark the property as a @Property. But since you're hard coding the value, that would mean you're dependent on the CST anyway from your Delegation, so if you simply put a static value in the CST, you could solve it that way. Or am I missing the point?

Re: Can we add 'hiddden' property in JavaTask

jjfutt — Wed, 21 Mar 2012 03:21:39 GMT

Hi Tiesebarrell:

Thanks for responding.

I am not sure what you meant by 'CST' - but I kind of understand your suggestion. Yes since the value is hardcoded, in my Java Implementation (that implementation JavaDelgate or ActivityBehavior interface) I can call 'WhateverSericeInterfaceDefinition'.getHardCodedValue(); However, that would be our last resort. Our first choice would be to able to say in the implementation class

execution.retrieveAllPropertiesOfTheCallingJavaTaskInterface();

This way, the implementation class doesn't have to know the exact class that was use to define the JavaTask node in the Service Palette.

Did I explain it properly?

Any suggestions or hints would be welcome.

Re: Can we add 'hiddden' property in JavaTask

tiesebarrell — Wed, 21 Mar 2012 09:32:44 GMT

Ah, I see. BTW: CST means CustomServiceTask, which is what you are making

Well, I don't think you'll be able to do that. The reason for this is that the BPMN that's executed for the process is in no way related to the modelled CST other than the properties are in Activiti-specific fields. The only way to get information from one to the other is through injected properties as you've been using or by using a static reference.

What you could do, which gets you a little closer, is to have the fields injected in the delegate, annotate them yourself (e.g. with your own annotation) and then create some kind of abstract class that contains a way to read all of those annotated properties. Since you're looking for specific things in the properties however, I don't really see a real advantage to that, since you're basically creating a general list of properties from a specific set, while you're also looking for specific properties in the first place. Seems like a lot of work with little purpose. Maybe I don't really understand what you're after.