I would like to poll the Dev community a bit to see what they would like in regards to remote code locations like this thread about remote < action-libraries >
I have done a little experimenting and found that FW, especially in FW5, will allow us to import code into the action with an eval() wrapper. This code is then treated as native, ready for use immediately. It does not need to be inside any type of fw… function, but can stand by itself inside an < action-javascript > container, thus that immediate readiness when the Javascript environment is instantiated.
Ideas so far are these:
Abstract: A system that allows for a central repository of Action code (not so much the similar issue of Scripty vs Moo and browser-side frameworks, this will hopefully be handled at a much deeper application level). Code like string manipulation; number functions; anything used ‘within’ an Action. Think JSON support or methods to call custom Applescript dialog boxes. Want to only maintain a single set of Action functions for all your Actions? This is the idea here.
Security: Since the system would use JS to pull in more JS, the core code could be ‘packed’/obfuscated with the normal means found on the Internet today (read things like Deans Edward’s JS packer, YUI compression, etc). For that matter, an actual encryption routine with a password could be used. Make them Public or Private
Portability: Additionally, the actual file location would not have to be known, as JS would traverse the file tree and find the file automatically.
Modularity: Suites would no longer have to reside in a single file, but rather could be modularized. Presuming nesting, the central files could themselves then be extended even further by further central files.
Predictability: Some form of dependency or versioning system (how to report back to user/Action and when?)
Ease of Use: Application at present is as easy as including one function in an action like remoteInclude(‘fileName.code’) (and, of course, the necessary definition of that function). This function be as simple as possible and call into a single handler file, also in this centralized system.
Updates: Changes to the centralized files automatically and immediately propagate through to the actions that use them as the files are read each time the dependent Actions are ‘activated’. Updates happen ‘instantaneously’.
I would like to investigate the following:
How does this work when called from inside action bundles?
Could this be used for genuine markup or images locations?
Can these calls be nested? (need to prevent recursion)
Is it possible to centralize fwParameters and other objects besides just javascript with this method?
Weaver, can you say a little more about this eval() trick? That sounds encouraging.
Not to hijack the thread, but what about a library object for interface elements? One thing that I have whacked into lately is the business of having to declare the same stack of files over and over in every Action, when all I really want is to include a single definition. As far as I can tell, action-library stuff has to happen inside the action-javascript block, and parameters are declared outside that block.
Weaver, if you set up fwInterface() or fwBeforeStartHTML() in your eval’d code, will it run the same as it would if you declared it within your action? That could be another big time-saver for large, multiple action actions.
My intial test have shown that functions and global variables defined in the eval()'d code ARE treated as native functions and are called as needed. In my test I used the fwInterface function with a global variable. Both were seen and responded to as expected.
The limitation I hit also, is that I have not yet been able to do anything other then JS code; fwParameters, fwMarkups, etc … no go. (markups are easy enough to do through external files, though)
I received one complaint back from FW that fwParameters cannot be defined through code. I forget what exactly triggered that warning. However, genuinely typed out parameters don’t seem to cause a problem when inside an < action-javascript > pairing. If the eval code could somehow ‘print’ the needed syntax… Another avenue is using < markups > (that can properly contain fwParameters) as a remote source (with the new ‘src’ attribute) for param definitions. Then an actual file could be written/modified to allow for expansion and centralization of file slots and choices.
What about the variables that FW has built-in? I think they were things like &title;, &date;, etc… Could these be modified/used to create ‘dynamic’ links to < markup > items? The crux is determining if the < markup > ‘src’ attribute could somehow accept a variable. Is it possible with some JS magic, or would something along the lines of Finder path trickery (if something like this even exists) to dynamically traverse folder Trees?
((this whole system will have to be tested in a more realistic environment, as there could certainly be situations that cause this whole thing to fall flat on its face))
A Question: Is the Action API finished looking for parameters by the time it gets around to processing JS code?
Nix what I was saying about < markups >. This seems to be a quirk of the application that allows thier location anywhere.
It now appears the API simply scans for key-phrases ‘< action-text…’ (and others) regardless of their location between the < item-action > tags. I am finding that I cannot get remote Markup items to carry through the syntax into the main Action item. Sorry to get your hopes up.
I have been able to create a basic framework to negotiate injection of centralized JS into an Action. Any feedback/suggestions/opinions would be greatly appreciated. Help would be appreciated even more. An archive with some sample code and a demo Action is located at the above link. It is still very rudimentary and definitely not ready for real usage yet, as many of the features and conventions are likely to change. But the framework provides these features currently:
Integration of remote JS into Action code
Nested libraries, one library calling another (will only inject each library only once)
Silent failure (optional), or Feedback to the user as to any problems that may have happened
Preflight trigger to alter injection material or run tests for injection: < loader > (not complete yet).
Central hub has version control, so developer can code for a specific version level and then let hub handle any necessary backwards compatibility
Strictly uses JS an FW functions, no Applescript currently used in the hub system
Basically is uses a small function inside the calling Action to initiate a more substantial call to a central repository of libraries and code. I have focused currently on just connecting the Action to the central ‘hub’. Now I can focus a bit more on expanding features and pushing envelopes. Again, hopefully FW will integrate a more low-level solution. But even so, I feel these efforts are not wasted as if/when a proper solution is released, the central hub can easier be redirected at the new location.
Ancillary Features:
Since code is straightforward JS, standard obsfucation techniques operate properly
I have not tested this fully yet, but I have a feeling the code from this method of integration would actually run ‘before’ missing file notices and other standard fwFunctions. And since it is executed from a naked command (not inside a fwFunction), it is called when the JS engine is instantiated, beating the call of any other function, even fwApplyError or fwInterface.
Limitations:
Functions propagate universally, variables declared via the normal ‘var’ do not. Instead a global object is present to which vars can be tied and accessed by all functions, remote and native. (‘var’ variables only really propagate downwards, Action > Hub > library, use caution in this regard). Library files should be considered Read-Only.
Cannot remotely include actual parameter data, ie < action-text >. This just does not seem possible as FW’s actual parsing appears to simply look for real instances of that text, even if trying to integrate via < action-markup >.
Alterations to the library files do not ‘dirty’ Actions the way normal editing does. Quick thoughts on workarounds include an actual action-parameter with a reference to a library version number. A change to the version number would allow for tests to update Actions. I am working on allowing return of the code as as string as well, so potentially the injected code could be ‘stored’ natively in case the Action is later not able to access the central library, or compared to the central code for changes and the Action dirtied as needed.
Future plans:
Addition of resource folder inside each library bundle
Version control for individual user libraries
Ability to pass arguments to/from libraries
Access to the actual Action/fwItem object by the preflight loader
Hopefully we can all work together on specific libraries, so things like: Image Manipulation, String Functions, Object Tests can be developed and linked together as a ‘core’ set