Hey Chris,
I’m reading the documentation page on resources. Does calling resources('images') indeed copy all files contained within to the server (overwriting existing files?)? If so, is it then not recommended to call resources on a directory containing many files, even if only a select few files will be referenced (e.g. as image_file components)?
Related question: why is it necessary to run resources('images') prior to creating image_file components from paths inside of images/?
Hi Michael,
Minor point: It’s best to think of resources('images') as a declaration, i.e. a note to MWorks saying “these files need to be copied to the server”, rather than as code that runs.
Does calling resources(‘images’) indeed copy all files contained within to the server (overwriting existing files?)?
Yes.
If so, is it then not recommended to call resources on a directory containing many files, even if only a select few files will be referenced (e.g. as image_file components)?
Copying more files means your experiment will load more slowly, as all the files are sent over the network at load time. But MWorks doesn’t care if you use the files or not, so I can’t say that it’s “not recommended”.
Related question: why is it necessary to run resources(‘images’) prior to creating image_file components from paths inside of images/?
It doesn’t matter where in the experiment you put that line. For instance, in this example, resource ('images') could be the last line in the MWEL file, and everything would work fine.
When I wrote the comment
// Need to declare the "images" directory as a resource in order to use an expression
// for the image stimulus' "path" attribute
I wasn’t trying to say that you needed the resource declaration right there, just that you need to include it somewhere for the example to work. If you omit it, the experiment will fail to load with the error:
Experiment packaging failed: Unknown variable: image_paths
To be clear, not all experiments require resource declarations. However, this particular example does require one, because the “path” attribute of the image_file stimulus is an expression instead of a literal path. That said, my feeling is that all new experiments should use resource declarations, as they make the experiment’s dependencies explicit and enable some things that aren’t possible otherwise.
Cheers,
Chris
Thanks, this is useful!
One small suggestion / question:
Is there a reason that the argument for “resource” calls be relative to the file location opened by MWClient (not necessarily where resource is called), unlike the parameter for “%include” (which is always relative to the location of the file where it is placed)?
It would be easier (maybe just for me) if resource calls were also relative to the file location in which they are called.
When writing an experiment consisting of several, modular MWEL files, there are usually some standard assets on disk that I’d like to include regardless of where the file I open in MWClient is located (the “main file”). But because their paths must be specified relative to the main file, it is not as easy to write modular MWEL components which use resources, without imposing assumptions on where the main file will be.
Hi Michael,
Is there a reason that the argument for “resource” calls be relative to the file location opened by MWClient (not necessarily where resource is called), unlike the parameter for “%include” (which is always relative to the location of the file where it is placed)?
Yes. Resource declarations are processed after the MWEL has been converted into a single XML file. At that point, the only “base path” available to MWorks is the location of the main experiment file, so that’s the path against which all non-absolute paths are taken to be relative.
When writing an experiment consisting of several, modular MWEL files, there are usually some standard assets on disk that I’d like to include regardless of where the file I open in MWClient is located (the “main file”). But because their paths must be specified relative to the main file, it is not as easy to write modular MWEL components which use resources, without imposing assumptions on where the main file will be.
I hear what you’re saying, but I don’t know that making resource paths relative to the MWEL file in which they’re declared is really feasible.
As a workaround, you could either:
Cheers,
Chris
Got it, thanks for explaining!
Michael