cancel
Showing results for 
Search instead for 
Did you mean: 

Custom extension -- possible to use expressions not text?

blezek
Champ on-the-rise
Champ on-the-rise
Hi,

  We've written a custom extension to Designer.  It appears that only <activiti:string> are supported for fields, but I would like to use <activity:expression>.  Does anyone know if this is possible?

I have an item with this annotation:

   @Property(type = PropertyType.TEXT, displayName = "Message Type", required = true, defaultValue = "Status")
   @Help(displayHelpShort = "Text string indicating event type")
   private String eventType;

   @Property(type = PropertyType.TEXT, displayName = "Text", required = true, defaultValue = "Status from Workflow")
   @Help(displayHelpShort = "Text")
   private String eventText;

which produces this XML:


       <activiti:field name="eventType">
          <activiti:string>Status</activiti:string>
        </activiti:field>
        <activiti:field name="eventText">
          <activiti:string>Starting Denoising workflow for ${BOKey} with tags ${Tags}  – Has Denoise? ${Tags.containsKey("Denoise")}</activiti:string>
        </activiti:field>

but I would like to have it produce this XML (notice <activiti:expression>, not <actviti:string>):

       <activiti:field name="eventType">
          <activiti:string>status</activiti:string>
        </activiti:field>
        <activiti:field name="eventText">
          <activiti:expression>Starting Denoising workflow for ${BOKey} with tags ${Tags}  – Has Denoise? ${Tags.containsKey("Denoise")}</activiti:expression>
        </activiti:field>

Suggestions are welcome!
-dan
9 REPLIES 9

tiesebarrell
Champ in-the-making
Champ in-the-making
Put simply, there's currently not an option to do that. Have you tried having the field injected as an Expression in the delegate? That's off the top of my head, not sure whether it makes a difference. I don't have an example at hand to check, sorry.

I think somebody suggested this before, so there might already be a request for it in JIRA.

In any case, it might be an idea to add an option to specify a field should support expressions, or maybe do it by default, but that would require some testing.

Could you check for a JIRA issue and +1 if there's one already?

blezek
Champ on-the-rise
Champ on-the-rise
Thanks for the quick response.  This is the conclusion I was coming to as well.  I did up vote the Jira issue (http://jira.codehaus.org/browse/ACT-877).

My delegate does use Expressions, but they come through as FixedValue and do not evaluate through JUEL, only returning the string.

I'll work around this for the moment, we mainly wanted to debug our workflows to log when variables are set and how JUEL evaluates them.

Best,
-dan

qnerd
Champ in-the-making
Champ in-the-making
Hi,
I added a short Patch to get this feature in http://jira.codehaus.org/browse/ACT-968.

Maybe it helps.

blezek
Champ on-the-rise
Champ on-the-rise
I added a short Patch to get this feature in http://jira.codehaus.org/browse/ACT-968.

Very helpful.  Would it be best to always use an expression?

I've been working around this with a hack in my JavaDelegate classes:
    Expression createEvaluatingExpression(Expression e) {
  // NB: This is a bit of a hack to make expressions work properly
  ExpressionManager expressionManager = Context.getProcessEngineConfiguration().getExpressionManager();
  if (e == null) {
   return expressionManager.createExpression("<null>");
  } else {
   return expressionManager.createExpression(e.getExpressionText());
  }
}

This code uses the ExpressionManager to return an expression, even if what was passed in was not.  This lets me evaluate a text-only expression as a full JUEL expression:

   Expression localText = createEvaluatingExpression(eventText);
   logger.debug("eventText " + localText.getExpressionText() + " eval " + localText.getValue(execution));

This way, I do not need to distribute a different version of Designer.

Thanks much,
-dan

qnerd
Champ in-the-making
Champ in-the-making
I added a short Patch to get this feature in http://jira.codehaus.org/browse/ACT-968.
Very helpful.  Would it be best to always use an expression?
I'm not sure. Maybe this results in unnecessary expression parsing. I tryed to get the same behavior as in FieldExtensionsExport:

[…]
          if (fieldExtension.getExpression().contains("${")) {
            xtw.writeStartElement(ACTIVITI_EXTENSIONS_PREFIX, "expression", ACTIVITI_EXTENSIONS_NAMESPACE);
          } else {
            xtw.writeStartElement(ACTIVITI_EXTENSIONS_PREFIX, "string", ACTIVITI_EXTENSIONS_NAMESPACE);
          }
[…]

If this patch looks ok for all of you, it would be nice if someone could merge it to the official designer source so it would be available in the next release?

Greetings,
Sven

tiesebarrell
Champ in-the-making
Champ in-the-making
Once we get around to the issue mentioned we'll definitely take a look at the patch, so thanks.

chillwabbitt
Champ in-the-making
Champ in-the-making
Another vote for this functionality - thanks.

tiesebarrell
Champ in-the-making
Champ in-the-making
This is planned for Designer 5.11, as you can track here: http://jira.codehaus.org/browse/ACT-877 . We expect to release Designer 5.11 before the end of the year.

chillwabbitt
Champ in-the-making
Champ in-the-making
Thanks