Requested Feature: Remote Library Files

I figured I would toss this out for others’ input.

—Remote <library> files— I find that I am often using exactly the same functions in my actions. I think it would be handy to have a mechanism that would allow writers to have a remote ‘support file’ with all of these common functions. In contrast to having to review and release new versions of all the actions that rely on those functions when changes to the ‘core’ functions need to be made.

Extended from this could be the ablity to check for existence of function/library file as well as its version number as new ‘features’ may be added to the common functions as time progresses. Maybe options would be disabled in the Action palette if a particular ‘support’ file was not present.

It would be an extension of the existing <action-include> command, but with the precautionary feature that the command include a switch that dictates the <library> is ‘remote’. ie: <action-include type="remote" name="somefunctionSet" minversion="1.1">

The extended benefit is that writers could develop ‘headless’ function sets for distribution to others. Maybe you have developed a regexp function for finding email addresses or a function to ‘clean’ a text string and escape necessary quotes? The same mechanisms used to protect actions now could be used to protect your own remote <library> files, if so desired.

quote

Hi Weaver, I’m sure I saw this added into one of the 4.x builds. I could be dreaming again but I think you can now link o external libraries with actions. Alan, can you shed any light on this. Also are the updated action documents in the pipeline? Thanks, Tim.

On 1 Aug 2006, at 5:52 pm, Weaver wrote: [quote:1565aa0b64]—Remote <library> files—[/quote:1565aa0b64]

quote

OK I’ve finally found what I was searching for. From the 4.1.2 release notes; [quote:9c873b1095]· Action-markup and action-javascript now has a ‘src’ parameter making it possible to have markup in a seperate file[/quote:9c873b1095] So not external library files but external JavaScripts and markups could be useful. I still need to test this myself as I’m not sure how FW handles ‘lost’ external files. Regards, Tim.

quote

Hi, I have been asking Alan for documentation about this for a while now. So far, nothing. He did warn me that if you edit an external library, the change won’t be seen by Freeway.

I’m hoping that the libraries can be encoded. I’ll have to lean on him some more to provide information on the subject.

quote

Thanks Tim, I missed that release note.

All the more reason for updated action documentation. I will wait and see what is released from SP (no pressure Heather). The whole ‘src’ thing could be a blessing or a curse depending on what and how specific the value needs to be.

Hopefully Paul’s mention about the actions updating is just a misunderstanding as I can see this feature being something as universal/useful as the scriptaculous-type JS libraries.

quote

[quote:f1fb7d8ba1=”Weaver”]All the more reason for updated action documentation. I will wait and see what is released from SP (no pressure Heather).[/quote:f1fb7d8ba1]

This stuff will have to come from someone else, because I don’t know the first thing about writing Actions or JavaScript. :lol:

The first proper edition of The Reference will include how to use Actions, but not how to write them. I think it will have to be an appendix of some sort.

quote

Here’s what I have found out so far, Hopefully it will work for a temporary documentation of this feature:

The syntax is as follows, supported in >4.1: [code:1:316a88f64b]<action-javascript src="BETA2.fwaction"/>[/code:1:316a88f64b]

[list:316a88f64b]>’src’ is a path from the calling action file to the remote file. The easiest thing to do is keep the remote files in the same folder as the calling action. >The format of the remote file it the same as that of a remote JS file in html. No opening or closing <action-javscript> tags, just get right to coding. >The above call may be made nested inside other <action-javascript> tags without error. The call is treated as a ‘known to be javscript’ code block that may be placed inside <action-javascript> tags, or may be left free-standing within the containing <action> tag. >FW only updates the remote file when starting FW, or when the calling Action has changed. So for development, it becomes necessary to make minor tweaks to the calling action file to cause FW to repoll the remote file. >The remote file does not work if it is encoded. An error is thrown by FW about illegal characters. >Remote files cannot contain further references to other remote files.[/list:u:316a88f64b]

Changes/Alterations I would like to see from the above: -Ability to encode remote files - thus adding a form of ‘security’ to the intellectual property of the remote file. -Ability to ‘name’ the remote file better. That is to say, instead of referencing the file by means of filename, rather let FW index the file for <library> and <markup> tags (which have the new property of ‘remote’), then calls for the remote files would look something like: <action-include name="remoteJSname" type="remote"/>. This might a bit too much change. I could live without this feature, but it would be nice. -The above change would allow the remote file to live anywhere in either of the Action file loations and not in a explicitly known location. -Since there appears to be no conflict with having the same function names defined locally and remotely, I think the remote call should include an ‘optional’ property. A clever author could program a ‘lite’ version of an Action. Then offer all the add-on options as part of an expansion pack. This also would allow the programmer to leave a door open for future improvements to his/her Actions that they don’t forsee at present. This may present a problem with correctly dirtying pages that include the Action.

quote

Hmm - not being able to encode these makes them pretty useless from where I’m sitting. I was hoping to slough out certain commonly used functions to libraries, but they would need to be encoded to make this viable for my Actions.

Did you ask Softpress about this? You got more out of them on this than I’ve been able. Well done.

quote

I was curious so I experimented on my end. I thought I would share my experiences/thoughts. None of the information came from SP.

Maybe I missed something, especially with the encoding, or maybe SP will make some updates. They won’t know specifically what we would like to see unless we tell them.

quote

[quote:94e48cc63a=”Paul”]Hmm - not being able to encode these makes them pretty useless from where I’m sitting.[/quote:94e48cc63a]

Although I generally agree encoding of external files is a must I can see how the current system can be very powerful for actions that rely on open source libraries to do some of their stuff. An OverLib action for example could be produced without having to embed the library in the action or read the code in at runtime. Regards, Tim.

quote

{{Sorry to keep digging up old threads}}

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?

quote

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.

Walter

quote

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?

quote

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.

quote

Update -CodeCentral: www.coastalrugs.com/Actions/developerstuff.html

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

quote