[EVAL] Split code into external *.groovy script files

[rednoah]

1.
These two format expressions are equivalent:

Code: Select all

{plex.name}

Code: Select all

{evaluate('plex.name')}

Code: Select all

{evaluate('/path/to/code.groovy' as File)}

2.
This approach can be used to refactor complex formats into one or more reusable components and split them into external *.groovy script files:

Code: Select all

{include '/path/to/TargetFolder.groovy'}
{include '/path/to/MovieNaming.groovy'}
{include '/path/to/MediaInfoTags.groovy'}

Code: Select all

{include "/path/to/MovieFormat.${y > 1980 ? 'Recent' : 'Classic'}.groovy"}

groovy.lang.Script
net.filebot.format.ExpressionFormatFunctions

* FileBot 4.8.6 (r6394) or higher is required for dynamic code evaluation.

[devster]

Thank you.
I had resorted to mustache templates (here) and they may still be useful for some cases (secret variables, credentials etc.) but this is definitely simpler.

[nothinghere]

I've tried using a few different things, but even having something as simple as:
test.groovy=>
{n}
and then doing movieFormat="{include 'test.groovy'}"
also tested movieFormat="{evaluate('test.groovy' as File)}"

results in an empty name..am I missing something? I may not have understood what should be in the groovy file, but from what I can see it should just be the same expression as we can already use in a one liner format?

*edit 2* updated to 4.8.6, but still getting empty file name

[rednoah]

test.groovy

Code: Select all

n

We're including Groovy code here, as opposed to FileBot Format Expression code, which interprets {...} delimited expressions as Groovy code. If we include Groovy code from within Groovy code, like in the example above, then Groovy code is expected.



YES:

Code: Select all

{evaluate 'n'}

Same as {n}

NO:

Code: Select all

{evaluate '{n}'}

Same as {{n}}

[nothinghere]

Oh, I see, I always was under the impression that the format expressions were just plain groovy. Shame on me.

Yeah, getting results now. Thanks!

[rednoah]

No worries. It’s a common misconception, since Groovy Code itself may also contain {} for close blocks or closures. So the semantics depend on the context.

[nothinghere]

After playing around a bit this is awesome.

However:
Trying to break out certain helpers as separate scripts it seems that there is an issue with loading external scripts unless everything is placed and run from the filebot portable folder (which I'd like to avoid since I have all my scripts backuped to a gdrive synced folder).

If I have a
tags.groovy file that grabs my preferred tag format, I can't seem to get it to load.

I've tried:
include 'getEditions.groovy' // this works fine if I place my groovy files in the lib, but if I run it from where I actually have my files it tries to load it from $CWD

After googling the recommended way is to do:

Code: Select all

def scriptDir =  getClass().protectionDomain.codeSource.location.path
include '$scriptDir/getEditions.groovy'

However, that blows up with

Code: Select all

AccessControlException: access denied ("java.lang.RuntimePermission" "getProtectionDomain")

I've tried granting access to all apps for that permission, but it doesn't seem to work.
Even doing:

Code: Select all

grant {
    permission java.security.AllPermission;
};

Doesn't work.


Is there some additional arguments I can give filebot to figure out which path to load files from, or is it all handled by the JVM?

[rednoah]

1.
Your code just doesn't do what you think it does:

Code: Select all

def x = 1
println '$x = 1' // $x = 1
println "$x = 1" // 1 = 1

http://groovy-lang.org/syntax.html#_str ... erpolation


2.
I'd use environment variables if I wanted to pass in some common folder paths for use in custom scripts:

Code: Select all

export FILEBOT_FORMAT_D="$HOME/.gdrive/FileBot Formats"

Code: Select all

_environment.FILEBOT_FORMAT_D

or via --def name=value if you need it in the format engine:

Code: Select all

filebot ... --def FormatFolder="$FILEBOT_FORMAT_D"

Code: Select all

{defines.FormatFolder}

[rednoah]

FileBot r6524 will now resolve include("files.groovy") relatively to the current script file by default.

[nothinghere]

FileBot r6524 will now resolve include("files.groovy") relatively to the current script file by default.

Great!


Thanks for pointing out that string interpolation thing, completely missed the single quotes difference (still threw the security exception but that's irrelevant now I guess).

The --def was exactly what I was thinking of as a workaround.

Thanks for the help!