New FARR plugin : FSubScript enable loading of multiple javascript plugins

[mouser]

please find an attempt at recursively searching for fsubscript.js to a limited depth.

great!

[ewemoa]

Attached, please find the latest.

Some changes include:

Fubscript/fscript.js:

• checking for existence of plugin search, trigger, and receive functions before attempting to call them

3 plugins are bundled with this archive:

• colors
• Akete
• Mixer - this is a repackaging of Webgrab

ecaradec, I had a question about some of the code in FSubScript/fscript.js -- specifically the .showSettings() and .settingsChanged() lines that sit outside of the for () {} constructs, but as I was composing this post, I think I figured out that I was confused, so please disregard the comments there

[czb]

Could you pls create a txt help file with all functions and other calls that fsubscript coder can use?
also pls bundle fscript.dll

[ewemoa]

May be ecaradec wouldn't mind updating his "fingers in the nose" guide

[czb]

I must say it is a great plugin 

Just an idea:

• not only fsubscript.js should be searched but maybe files fsubscript*.js so you can have more files in one folder

Here is my corrected fsubscript plugin

http://dl.getdropbox.../FARR/FSubScript.zip

and JScalc:

http://dl.getdropbox...4571/FARR/JScalc.zip

fsubscript changes:

• all fsubscript*.js are loaded (for example fsubscript_JSON.js)
• implemented onSetStrValue
• implemented onInit

JSCalc changes:

• rewriten to work with fsubscript only
• new TriggerCharacters settings added where you can define special characters which are to trigger JScalc (default is "TriggerCharacters":"/\\$\\*\\+\\-\\^\\(\\)" )

[ewemoa]

Haven't tested yet, but hope to soon.

ecaradec: czb and I were chatting and started to wonder about extending things via prototypes -- e.g. String and trim.  Do you have any good ideas about how this might be managed to reduce (or eliminate?) conflicts among code produce by various plugin authors?

[ewemoa]

Some initial comments on a few things I've looked at so far:

I noticed that for onSearchBegin(), a sub-plugin (?) defines search(), for onReceiveKey(), a sub-plugin defines receive(), and for onProcessTrigger(), a sub-plugin defines trigger().  I found it a little odd that for onInit(), a sub-plugin defines onInit() -- similarly for onSetStrValue().  I think init() [if that's possible] seems somehow better-fitting in terms of naming -- either that or change all of the other things to match the names used by fscript.js.  Or may be some other idea?  What do you think?

I'm not so clear on how fscript.js/onSetStrValue() should behave -- specifically, the return value seems to get decided purely on whether a single sub-plugin returns true.  Is that what we want?  What if more than one sub-plugin returns a value and one returns true while another returns false?  May be the current implementation is what we want -- which would be fine by me, I just don't currently have a sense of what it should be

onInit() in the original fscript.js took a single parameter iirc, in the most recent code candidate the sub-plugin's onInit() doesn't take a parameter. I wonder whether mirroring the original interface is preferable or not.  May be it's not a big deal.  Any thoughts?

I'm not sure about loading all fsubscript*.js files -- I wonder whether the loading order might matter in some cases and with the way the code is currently, a sub-plugin writer can only control this based on coming up with appropriate filenames.  I hadn't really thought about multiple files per sub-plugin so I start to wonder about the potential consequences and alternative designs

[ecaradec]

I think sub-plugins should not extend global state. fsubscript could expose many useful functions so that plugin developers have less need for sharing things.
Inclusion of other files can be done with eval(getTextFile("json.js")) if your plugin is too big to practically work in one file.

I found it a little odd that for onInit(), a sub-plugin defines onInit() -- similarly for onSetStrValue().  I think init() [if that's possible] seems somehow better-fitting in terms of naming -- either that or change all of the other things to match the names used by fscript.js.  Or may be some other idea?  What do you think?

Given it's done one way, I prefer it to stay the same so that we don't loose time talking about useless guidelines.

I'm please to see you on board czb

[ewemoa]

I didn't exactly follow what you meant about the naming of things, but thanks for the review and feedback.

Since my experience and understanding of FARR and FScript is rather limited, I guess my comments are likely to be too

[czb]

hi,

onInit() onSetStrValue()

Yes you are right, that it should be unified. I will leave all naming upon you so I will definitely change it into Init() and SetStrValue

I'm not so clear on how fscript.js/onSetStrValue() should behave -- specifically, the return value seems to get decided purely on whether a single sub-plugin returns true.

 
Well this behaviour is for pcommand where you have to tell FARR that at least 1 plugin treated it so FARR would not display error message. I do not know other usage of returning value to FARR from OnSetStrValue, so if you know of any we can implement it But at least some implementation is necessary because pcommand is used quite often.

onInit() in the original fscript.js took a single parameter iirc, in the most recent code candidate the sub-plugin's onInit() doesn't take a parameter. I wonder whether mirroring the original interface is preferable or not.  May be it's not a big deal.  Any thoughts?

I did it so because there is already curdir implementation via directory variable, so why to have it twice? So I would keep it without any parameter

I'm not sure about loading all fsubscript*.js files -- I wonder whether the loading order might matter in some cases and with the way the code is currently, a sub-plugin writer can only control this based on coming up with appropriate filenames.  I hadn't really thought about multiple files per sub-plugin so I start to wonder about the potential consequences and alternative designs smiley

Inclusion of other files can be done with eval(getTextFile("json.js")) if your plugin is too big to practically work in one file.

Well aceradec showed one way which is in fact very easy and straitforward, but still I would keep name variation just for the case when you want to have several small subplugins in one directory which can easily occur. But we can discuss that and if we find it as "baad" idea we can always erase it

I think sub-plugins should not extend global state. fsubscript could expose many useful functions so that plugin developers have less need for sharing things.

Yes exactly that is what I proposed to ewemoa. To have list of useful functions which make js developers life easier. The problem is to decide which to add on the list

I have also one request to ewemoa and aceradec and maybe mouser. Could one of you pls create any environment where we could colaborate on fsubscript plugin? Like propose new modifications etc... I have no experience with that so I will leave it on somebody else