Scripting / importCommands

Zendesk API User

• 30 octobre 2023 16:25

Author: seegers
Publication Date: 10/30/2023 16:25

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.

Associé à

• Scripting

0

• 

  Zendesk API User

  • 15 novembre 2023 07:55

  Author: hoebbel - 11/15/2023 7:55
  

  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.html

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

  Best regards
  Holger

  0
• 

  Zendesk API User

  • 12 août 2025 18:01

  Author: mbergmann - 11/15/2023 18:06
  

  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

   

  0

Vous devez vous connecter pour laisser un commentaire.