Questions & Answers

[seegers]

Hi everyone,

by now I am fairly regular writing scripts to manage changes in various FS projects and to support editors with extended functionality. Over the time, I have developed a few helper functions that I keep reusing in my scripts.

-> Is there a way that I could store them (ideally in another script/file in the Template/MediaStore) and import them and use those methods in other scripts?

I am aware that there is according to the BeanShell Doc the "importCommands" command that can read another file from the filesystem. I would prefer however to manage everything on the same level within FirstSpirit. I would appreciate any suggestions that you have on how I can handle this better. 🙂

[hoebbel]

Hello seegers,

I would choose a different approach. Instead of writing Beanshell scripts (for the execution of which a Beanshell interpreter must be started each time), I would write a module with corresponding executables. Similar (or all) scripts can be combined in a module. Only the following script code is then required:
#!executable-class
public_name //or class

Further information (unfortunately only in German) can be found here:
https://docs.e-spirit.com/odfs/edocs/mdev/firstspirit-mod/komponenten/komponenten-typ/public/index.h...

The FirstSpirit Module Gradle plugin can be used to develop the module:
https://github.com/e-Spirit/firstspirit-module-gradle-plugin

Best regards
Holger

[mbergmann]

Hi,

I‘d also strongly recommend modules instead of scripts.

Scripts are interpreted which means that errors are only identified when the problematic code part is really executed. One prominent example is a typo in a variable name inside conditional statements. Or the usage of FS API that at some time gets deprecated and later removed. Or the usage of non official API. An IDE and build process can help very much here. 

And of course a module allows a much better structure including utility classes/methods which can be used centrally.

For some cases, you even don’t need a Script object but can use one of the plugin classes/interfaces. 

The only exception  in my opinion are pure „configuration scripts“ (e.g. in workflows or schedules) that just put some values into a map or context.

By the way - concerning using the public name vs. the (full qualified) classname after the #!executable-class - I‘d recommend the public name because that adds another abstraction layer which allows refactoring of package or class names without having to worry about necessary changes in the project.

Michael