Namek Dev
a developer's log

The Console: script management

March 22, 2016

The biggest feature of my console software is ability to code own “commands” - scripts. It’s supposed to be easy and quick for programmers. I’m not trying to design my own DSL language or make users install some weird packages into system. JavaScript and console API is all you need to know to code your custom scripts.

If one of goals of The Console project is to make easy custom scripting then it’s logical that you need some way to manage your scripts. Putting all scripts in one file or even all scripts in one folder would be a mess. So, how to manage those files? How The Console deals with it?

Script in The Console is a simple text file that contains JavaScript code. Scripts are located in any subfolder of %APPDATA%\TheConsole\scripts . Scripts can be created, copied and modified as any other file and job of The Console is to react on those changes.

So… a few questions have shown up.

1. How to track scripts?

Loading algorithm is quite straightforward:

  1. load file and remember it’s location
  2. watch for changes

Standard Java API makes it able to watch (monitor) folders for changes thanks to java.nio.file.WatchService. However, it doesn’t work for folder tree. That’s why I used custom modification of Philipp C. Heckel’s RecursiveWatcher.

As for changes, I’m only (currently) interested in script modification. I just want to reload it’s content. Although being able to freely move it between subfolders is useful (and works) I haven’t completely decided on edge case behaviour when file is moved into another folder because there’s a dilemma around it - what if other script is named alike? How to track scripts?

2. How to modify script?

Possible options are:

  1. built-in editor
  2. some built-in REPL CLI to manage scripts
  3. just a button or a quick command to open  %APPDATA%\TheConsole\scripts folder (in File Explorer) and let user modify files using however he likes

Here’s how it goes:

  1. Obviously, because it’s JavaScript, we don’t need custom built-in editors. It could take a lot of time if I wanted to create configurable coloring or code completion - because who know, how big scripts people will make? Built-in code editor is out of project scope.
  2. CLI is not hard to be made but I’d rather think of API to create custom CLI-s, e.g. for math just like you would use Octave in CLI. Having that, it would be actually quite simple to create CLI for script management. But that’s a topic for another post.
  3. little button on the top of window to open a folder will fit. Sublime Text, Notepad++ or Notepad? Edit your scritps as you want.

3. How to group scripts?

Group by folders, of course! But here comes very great dilemma!

Some scripts are about file computation (like calculating md5 of file), some take text/number arguments but other are very custom:

  • Custom scripts to open websites? OK! Create websites  folder and put those in there!
  • Custom scripts to calculate something? OK! Create calc  folder!
  • Custom scripts to process text? No problem! Create text  folder.
  • whatever else to do whatever else? Sure! Create whatever  folder!

Or encapsulate even more (in subfolders), I don’t care!

So where’s the dilemma, you ask? Currently, I have some core scripts e.g. core/data/md5file.js , core/filesystem/cd.js , core/filesystem/pwd.js or core/filesystem/ls.js. For me these are core. For others my core scripts could be candidates for deletion.

(note: this dilemma will strike back within future post that will cover Script Sharing)

4. Finally, how to share script?

“Sharing is caring”, they say but it’s also about increasing usefulness of effort. Simply copying script files is easy but not efficient. Real sharing here is supposed to be about putting your work into some greater online library that more people have access to. Of course, if your heart is open sourced.

That’s why I have to design online library and I’m going to cover it in a future post.

Daj Się Poznać, the-console
comments powered by Disqus