Is it possible to create a behaviour class in ScriptRunner?

[Stefan Stadler]

Hi guys,

I am currently trying to re-use existing functionality/code in more than one behaviour without copying the code into multiple script files.

At the moment, all the scripts start with 

@BaseScript FieldBehaviours fieldBehaviours

This limits the reusability a lot because this (as far as I could see) cannot be used in a class. 

Do you have an example of how to use ScriptRunner behaviour in a class and just call a function instead of a plain script? At least the file type configuration lets me assume that this should be possible - I just do not know how....

Thanks for your help!

Stefan

[Radek Dostál]

Not sure if I follow what you have in mind but I'll try to describe a bit how I understand it and how I work with this with hundreds of script files.

When you run a "plain" script (just start writing line by line) it will be compiled into a semi random class such as Script123.java, what you wrote will more or less be inside a generated "run" method, and the run method is called when the script triggers. More or less, give or take. Interesting fact is that this Script123.java will extend "Script" which stipulates the run method.

Example:

if (something)
  //do something

When you create a class, it needs to extend the Script class - every script does this, the one that gets auto generated does this as well, and your class must implement the "run" method which will be called when the script triggers. Basically the same thing except that you are creating a class on your own rather than having it be auto generated.

Example:

class TheThing extends Script {


  private static final String ABC = "abc"
  private int aNumber

  // constructor will be called by the way, which is neat
  TheThing() {
    this.aNumber = 5
  }

 
  @Override
  Object run() {
    if (something)
      //do something
  }
}

When you look closer into FieldBehaviours, you will notice that it's just a wrapper by adaptavist, which does in fact already do something similar:

public abstract class FieldBehaviours extends Script {
  // bunch of nice methods here

  // such as getFieldById() etc. etc.
}

As far as BaseScript goes, you can use it either way, as an annotation, or by extending the class instead.

The documentation for BaseScript is a bit mouthful but it eventually clicks once you do some testing around it.

So in my case, I just do the following in regard to behaviours..

abstract class BaseBehaviour extends FieldBehaviours {

  static final Logger log = Logger.getLogger("ScriptRunner-BaseBehaviour")
  static final SomeOtherUtil someOtherUtil ..
  static final SomeOtherOtherUtil someOtherOtherUtil ..

  String someMethodLikeGettingFieldsWithLoggerSoIKnowWhatIsFailing ..
  String someOtherMethodToDoSomething ..
  
}

This is my "base" class for BaseScript, I get the benefits of FieldBehaviours, as well as the benefits of any other extra methods or variables I define here.

Then, I just create a bunch of files that will either use BaseScript annotation (which is easier for less technical users around me, they do NOT like whole classes), or I could just create a concrete class that extends it, so long as my concrete class extends BaseBehaviour, and implements the run method.

I think that even with a class you could still annotate it, but it just feels wrong, extending feels more proper imo.

What I'm trying to show with these examples is - BaseScript is pretty similar to extends. You can practically replace annotating it with extending the thing. I'm sure there are some deeper level differences probably, but I can't think from the top of my head what those might be.