DonationCoder.com Software > FARR Plugins and Aliases

New FARR plugin : FSubScript enable loading of multiple javascript plugins

<< < (12/12)

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?

--- End quote ---
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()
--- End quote ---
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.
--- End quote ---
 
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?
--- End quote ---
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
--- End quote ---
Inclusion of other files can be done with eval(getTextFile("json.js")) if your plugin is too big to practically work in one file.
--- End quote ---

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.
--- End quote ---

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

Navigation

[0] Message Index

[*] Previous page