Hi Dave,
I'm just starting out converting our exporter to a xJSFL module and I'm not sure whether the custom module needs to be in the xJSFL/modules folder? If they do, it seems a little messy, although I suppose I could make it a git submodule (even though they suck :)).
Also, assuming it's OK to do so, you should update your docs to remove the absolute paths from your Sample Module code here: http://www.xjsfl.com/support/guides/extensibility/modules#swf-panel.
-Aranda
From the point of view that modules/ is already in a repo? I suppose you could say that, but the framework needs somewhere to stick its code.
But yes, you should put the module in here, in a subfolder.
So, I've never really used GIT submodules, but I just did a little test using TortoiseGIT "Submodule Add" and it seemed to be pretty straightforward.
The other option you have is manually loading a module from another folder / repo on your hard disk, using custom code in your user bootstrap, or an auto-loaded JSFL file that you just stick in user/jsfl/libraries/:
xjsfl.modules.find('z:/Development/Flash/xJSFL Custom Modules/', true);
Oh, and the absolute path in the Module example? That needs to be there so that at authoring time, your published SWF can access any module assets, i.e.:
setup('Exporter', 'file:///z|/Development/Flash/xJSFL/modules/Exporter/', 'file:///z|/Development/Flash/xJSFL/');
When the published SWF is finally running as a Flash panel, it will be able to access JSFL, and will automatically update these paths with the current live ones.
The reason for this is that at authoring time, there is no JSFL, so there's no way to determine the location of xJSFL, or the module, so the paths need to be hard-coded. It took a while to figure out the best way to do this, and this is the best compromise I could come up with. If you have any better ideas, I'm all ears!
Meanwhile, I've stuck a note in the code.
Finally, at some point (probably when I release the Pro Tools) there will be a Module Generator. This way you fill in a few form fields, and have the base code generated for you. Should save confusion setting up modules... which are by their very nature, a bit technical.
Cheers,
Dave
Thanks for the explanations Dave. I'll try a few options and see what works for me with the module path. The main concern is ease of deployment for the end users, but the ability to have my module in my own git repo is important too.
So far it doesn't seem too bad - I haven't progressed very far yet but the Sample Module is a nice bare bones place to start.
FYI, this is what my bootstrap output looks like, loading a custom module from another drive:
> xjsfl: INITIALISING MODULES...
> xjsfl: REGISTERING MODULE "SAMPLE MODULE"
> xjsfl: added 6 search paths for "E:/Projects/xJSFL/modules/Sample Module/"
> xjsfl: assets are already up to date
> xjsfl: REGISTERING MODULE "SNIPPETS"
> xjsfl: added 11 search paths for "E:/Projects/xJSFL/modules/Snippets/"
> xjsfl: assets are already up to date
> xjsfl: RUNNING USER BOOTSTRAP...
> xjsfl: loading library: load modules
> xjsfl: LOADING POCKET GOD MODULE...
> xjsfl: REGISTERING MODULE "POCKET GOD TOOLS"
> xjsfl: added 14 search paths for "H:/Perforce/Bolt Creative/dev_Mesh_Desktop/iPhone/BoltLib/xJSFL/modules/Pocket God Tools/"
> xjsfl: assets are already up to date
> xjsfl: ready!
=================================================================
The loading code is placed in /user/jsfl/libraries/load modules.jsfl (as you can see above, and so is loaded automatically via the user bootstrap, which finds and loads all libraries) but could just as easily be placed in the user bootstrap itself (I just don't as it's part of the GitHub repo).