Module paths
  • ArandaAranda July 2012

    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:




  • DaveDave August 2012

    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.



  • ArandaAranda August 2012

    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.

  • DaveDave August 2012

    Deployment should be as easy as copying the module folder in question from Computer A to Computer B.

    There are plans in the roadmap for a zip module installer (I've done some testing and it's possible on both Mac and PC) but that's after a long list of other to-dos!

  • DaveDave August 2012

    FYI, this is what my bootstrap output looks like, loading a custom module from another drive:


    > xjsfl: added 6 search paths for "E:/Projects/xJSFL/modules/Sample Module/"
    > xjsfl: assets are already up to date

    > xjsfl: added 11 search paths for "E:/Projects/xJSFL/modules/Snippets/"
    > xjsfl: assets are already up to date

    > xjsfl: loading library: load modules


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

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with OpenID Sign In with Google Sign In with Twitter

Sign In Apply for Membership