topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Tuesday March 19, 2024, 5:57 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Last post Author Topic: New FARR plugin : FSubScript enable loading of multiple javascript plugins  (Read 51033 times)

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
please find an attempt at recursively searching for fsubscript.js to a limited depth.

great!

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
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

  • Honorary Member
  • Joined in 2007
  • **
  • Posts: 336
    • View Profile
    • My open-source online piano game
    • Donate to Member
Could you pls create a txt help file with all functions and other calls that fsubscript coder can use?
also pls bundle fscript.dll :)
My open-source online piano game: https://github.com/musicope/game

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
May be ecaradec wouldn't mind updating his "fingers in the nose" guide :)

czb

  • Honorary Member
  • Joined in 2007
  • **
  • Posts: 336
    • View Profile
    • My open-source online piano game
    • Donate to Member
I must say it is a great plugin  :Thmbsup:

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":"/\\$\\*\\+\\-\\^\\(\\)" )
My open-source online piano game: https://github.com/musicope/game

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
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

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
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

  • Honorary Member
  • Joined in 2006
  • **
  • Posts: 410
    • View Profile
    • Blog & Projects
    • Read more about this member.
    • Donate to Member
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 :)
Blog & Projects : Blog | Qatapult | SwiffOut | FScript

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
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

  • Honorary Member
  • Joined in 2007
  • **
  • Posts: 336
    • View Profile
    • My open-source online piano game
    • Donate to Member
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 :)
My open-source online piano game: https://github.com/musicope/game