Two-pane web file manager Cloud Commander
There are a lot of file managers, but there is one, about which, I think, it will be interesting for many to learn. After all, it is two-pane, it works in a browser, is equipped with an editor (with syntax highlighting) and a console, consists of a client and a server, and is written in JavaScript / Node.js.
')
Website: cloudcmd.io
Demo: heroku , jitsu
The first computer book I read was Windows: Lab Wizard . She talks about a variety of utilities under Windows 9x. Some of them no longer exist (Zip Magic 2000, for example), others are actively used, and most importantly, are being developed to this day (Total Commander). Most of all I liked the section about file managers. I did not have a computer yet, but even then I realized that using Explorer was not serious, and it is much more correct and convenient to use Two-pane file managers. I tried everything that was in the book behind every computer I was able to go to. Most of all, of course, I liked Total Commander. He is the best in his business is undeniable.
A few years later, I had a computer. After some time, next to Windows, I installed Linux, and wanted to find something suitable for convenient file management. I did not really get it. Yes, Midnight Commander's * nix is the best, that's true. But there were no many functions to which I was so used to using Total. They were not in the graphic managers. One of these functions is moving the current file pointer while typing a name (when there are a lot of folders, and I have a lot of music, flipping through the list is not the most pleasant thing to do).
As a result, it was more pleasant for me to listen to music, watch videos, and manage files in a bare console. What I stopped for a while.
A few years later, having settled in a small company, I realized that I would be less likely to fall for my computer. And indeed, it was the way things happened that more often I work at other people's computers. And since it is not very easy to get used to the new, I began to increasingly use languages and development tools that work in the browser and do not require installation, configuration, and other long-term things. I started using Cloud9 , Koding and, of course, GitHub .
I was excited about the idea of cloud services, I was so pleased with the openness and possibilities of these projects that I started to make my own. This is the file manager of Cloud Commander.
Most analogues are written in php, which is not very close to me. Most of the code I write in JavaScript, Therefore, respectively, I would like to see more applications written in a language that may not be the best, but the most common, that's for sure.
There are a lot of file managers for the web. But, practically, each of them has several fundamental problems:
From good managers, I can give, for example, the following:
The above applications do their job very well. But from an ordinary file manager, for example, I am waiting for another. And if there is a need to work in the browser - why not make programs of this type more friendly, not only for ordinary users, but also for more advanced ones who spend most of their time in classic two-pane file managers.
Sane two-pane file managers who would work in the browser as I could not find 2 years ago, when I started writing my own implementation, I cannot find it now. Although regularly monitor this issue.
At first, I had ideas to continue someone's initiatives, to connect to the project, so to speak. I found an analogue (unfortunately I don’t remember the link) of the total commander on SourceForge, with a web interface, it was written in PHP, which I was playing with at the time. All his code was folded into one file, and I didn't really want to deal with that. Moreover, in those days, I began to be actively interested in Node.js, and I wanted to try it on a new project.
From the interesting things that have appeared since that time, I can single out, perhaps, that Metro Commander . True, there is no way to touch it, since it works only on win8, and not in the browser, but natively. But in the screenshots it looks impressive. Otherwise, there are no special movements in this direction, at least in places where I search.
And so, what makes Cloud Commander so interesting that you should pay attention to it? We will analyze these points in more detail because it is really important.
Of the most interesting features are the following:
The main difference is a two-pane interface with familiar keyboard shortcuts. But that's not all. In contrast to other file managers running in the browser, Cloud Commander has a console and editor.
The editor supports syntax highlighting for more than 110 languages. The file format is determined by its extension. The source code of Cloud Commander is corrected in it (and this article is also written in it).
The console allows you to execute commands on the server, and no matter whether it is Linux, Mac OS or Windows. The server running Cloud Commander is controlled from the console right in the browser.
An important difference is also Node.js as the platform on which the File Manager runs. No more php + apache.
The presence of advantages also implies the existence of disadvantages, without this in any way. The most significant:
These are fundamental flaws. If we talk about urgent problems, then there are some. In the editor:
As mentioned above, Cloud Commander consists of a client and a server. About the client has been a little said, so let's start, probably from the server.
The server can work without the established dependencies, while it goes into the mode of limited operation. In this mode, the console does not work, js / css / html optimizations are not performed, copying, moving and deleting folders does not work. After installing modules written in package.json, use:
Some modules work both on the client and on the server, this is a diff-match-patch , developed a long time ago, but it works very stably.
On the client, the list of used modules is much wider. It:
Most of the questions are probably caused by the archiver on the client. It is used to reduce the size of data sent to the server by the editor. This mode can be enabled (and disabled) in the settings. In fact, as I said, the bottleneck in the client-server application is data transfer. Packing (and unpacking on the server), in turn, is extremely fast.
But the text does not have to be sent always. It is advantageous to send to the server only the data that has changed, that is, the patch. Therefore, if, between revisions, the file on the server has not changed - a patch is sent and applied on the server (provided that the file does not weigh very much, because each such operation is loading the entire file into RAM), if changed, compressed data is sent . Due to this, the processing speed is very close to the desktop application.
Downloading data from the server is also not needed every time you open files. Therefore, when opened (files) are placed in localStorage, in a place with a sha-1 hash. And, if the hash has changed (without our knowledge), the file is loaded again, otherwise the hash is updated each time the file is saved. The same is true of directories. If this option is enabled, the contents of the directory are loaded once, and to update it, press Ctrl + R (or delete / create a new file / folder).
In such a large application with a huge number of modules, it would be very difficult to figure out if all the files were loaded immediately, when the page was loaded. Such an application would be difficult to maintain, since from time to time some programs are updated, while others become obsolete and require replacement. Therefore, the application is divided into modules: client and server.
Client modules are loaded as needed. If a person needs a menu, it loads, if the console did not come in handy for the entire session, its files did not even load and did not start to run, which significantly increases the speed of work and saves resources both on the client and on the server.
Threads node.js is a very powerful tool that is radically different from what is in other scripting languages. In the process of immersing in node.js, the thought that files can be merged into a stream and given as if it were one file did not leave me. I thought there would be delays in speed, but no. Everything works like a clock, and there are no special slowdowns, but instead, it is possible not to merge files into one, and not to load them sequentially, but to load them as one file .
This idea, from recent times, began to be promoted in jsDelivr . And I think this is the right direction.
In short: if you need to load the jquery.js file and jquery.fancybox.js, you can do it this way:
Using the ":" symbol, file names are separated from each other, thus, absolutely anything can be combined, and this should not affect the server’s performance, since files are read sequentially, but immediately after reading they are given to the client.
If the file cannot be read, an error message is sent instead, after which the stream closes.
Enough is said about the application itself, but there are a few things that I would like to say about the development. As already mentioned, Cloud Commander is written in itself.
The project is hosted on a githaba . It has two branches: dev and master .
The first is the option that is being developed, all edits are made there, and although ideally everything should always work, sometimes different incidents happen.
In the second branch is the latest stable version. It can always be taken from the repository, everything should be fine with it.
After each push, the code is sent to the travis.ci system, where the prescribed tests are run, and the code is deployed to NodeJitsu and Heroku.
And if something does not work as it should, the letter immediately arrives, and the icon in the repository changes its color to red.
If, on any of the services, Cloud Commander does not respond, on the site , at the very top, next to the links, not green circles, but red ones are displayed. If the answer is long - yellow.
The project uses Gulp , which automates all routine actions: checks js, css, runs tests, etc.
Once I came across an article that talked about the naming style for commits accepted in Angular. In fact, this is a very important process. Changes, corrections, refactoring, etc. have their own prefix, and during the release, commits with the
I want to thank the reader for having come so far (even if he just squandered it). I hope the article was useful and interesting. It may be continued, wait and see.
This is my first article on Habré, if there are typos, suggestions, comments - please in a personal or hidden branch in the repository . I will try to correct.
')
Website: cloudcmd.io
Demo: heroku , jitsu
Foreword
The first computer book I read was Windows: Lab Wizard . She talks about a variety of utilities under Windows 9x. Some of them no longer exist (Zip Magic 2000, for example), others are actively used, and most importantly, are being developed to this day (Total Commander). Most of all I liked the section about file managers. I did not have a computer yet, but even then I realized that using Explorer was not serious, and it is much more correct and convenient to use Two-pane file managers. I tried everything that was in the book behind every computer I was able to go to. Most of all, of course, I liked Total Commander. He is the best in his business is undeniable.
A few years later, I had a computer. After some time, next to Windows, I installed Linux, and wanted to find something suitable for convenient file management. I did not really get it. Yes, Midnight Commander's * nix is the best, that's true. But there were no many functions to which I was so used to using Total. They were not in the graphic managers. One of these functions is moving the current file pointer while typing a name (when there are a lot of folders, and I have a lot of music, flipping through the list is not the most pleasant thing to do).
As a result, it was more pleasant for me to listen to music, watch videos, and manage files in a bare console. What I stopped for a while.
The reasons
A few years later, having settled in a small company, I realized that I would be less likely to fall for my computer. And indeed, it was the way things happened that more often I work at other people's computers. And since it is not very easy to get used to the new, I began to increasingly use languages and development tools that work in the browser and do not require installation, configuration, and other long-term things. I started using Cloud9 , Koding and, of course, GitHub .
I was excited about the idea of cloud services, I was so pleased with the openness and possibilities of these projects that I started to make my own. This is the file manager of Cloud Commander.
Analogs
Most analogues are written in php, which is not very close to me. Most of the code I write in JavaScript, Therefore, respectively, I would like to see more applications written in a language that may not be the best, but the most common, that's for sure.
Web file managers
There are a lot of file managers for the web. But, practically, each of them has several fundamental problems:
- imitate the Windows Explorer interface (making the manager less convenient than the Explorer);
- operations with files mostly take place on different pages, which is completely non-interactive (although it can be explained by the fact that managers are mainly written in server languages);
- work extremely slowly (they do not use local storage and other HTML5 functionality to speed up work, since they are written in server language, and JavaScript is used only for basic things such as ajax, and it’s still good if the data is sent in json and not in chunks of html) code);
From good managers, I can give, for example, the following:
- ElFinder (contains problem 1 and 3 (and also 2, try to download the file, and you will see a popup that you need to close by yourself)).
- Pydio (looks very promising, but instead of bringing the familiar interface to the web, it creates a new paradigm (not that it would be bad, but still).
The above applications do their job very well. But from an ordinary file manager, for example, I am waiting for another. And if there is a need to work in the browser - why not make programs of this type more friendly, not only for ordinary users, but also for more advanced ones who spend most of their time in classic two-pane file managers.
Two-pane file managers
Sane two-pane file managers who would work in the browser as I could not find 2 years ago, when I started writing my own implementation, I cannot find it now. Although regularly monitor this issue.
At first, I had ideas to continue someone's initiatives, to connect to the project, so to speak. I found an analogue (unfortunately I don’t remember the link) of the total commander on SourceForge, with a web interface, it was written in PHP, which I was playing with at the time. All his code was folded into one file, and I didn't really want to deal with that. Moreover, in those days, I began to be actively interested in Node.js, and I wanted to try it on a new project.
From the interesting things that have appeared since that time, I can single out, perhaps, that Metro Commander . True, there is no way to touch it, since it works only on win8, and not in the browser, but natively. But in the screenshots it looks impressive. Otherwise, there are no special movements in this direction, at least in places where I search.
Special features
And so, what makes Cloud Commander so interesting that you should pay attention to it? We will analyze these points in more detail because it is really important.
Of the most interesting features are the following:
- Work in the browser. This is an important feature that entails a series of strengths and weaknesses, on which everything depends. The main thing is probably that if you do not use the browser (such people really are?) - this program is definitely not for you (in other words, it’s not so difficult to change, as seen in the next paragraph).
- Client-server architecture. This follows from the first paragraph, to do absolutely everything that I want with the means of the browser does not work. But this is a huge plus: the division of responsibility (logic and graphics are used by different parts of the application, which allows, for example, writing a native client for any OS, without changing the server code), which, in turn, allows you to rewrite part of the application to another language, guided by the communication protocol of the client and server (this will be discussed below).
- The code is written entirely in JavaScript, which means that parts of the code are completely reused, both on the client and on the server, which makes you more serious about what you write. Design the code so that it does not depend as much as possible on the environment in which it runs, whether it is a browser or node.js.
- Ability to work with JavaScript disabled in the browser. Most of the operations will not be available, but you can walk around the file tree and download the necessary things without problems.
- Modular structure. From the very beginning it was clear: if you write everything from scratch, then you may end up with nothing. Therefore, only the main part (core) is written from scratch. Such functionality as: viewing, editor, console, etc. These are modules written by other people. Any of them can be replaced (if it is no longer supported, or if a serious analogue appears), and some (editor and console) have already been replaced, but more on that later.
- Responsive interface. The file manager will work in a mobile phone and tablet browser. If the screen does not fit the second panel, only one will be displayed. And it will respond to tachi, not clicks.
- The ability to interact with Cloud Services (DropBox, GDrive, etc.)
- Ability to download and upload files using Drag'n'Drop.
- The ability to load data from a file (on the desktop) into the editor using Drag'n'Drop.
- Ability to change jshint rules by editing the .jshintrc file, which will affect all js-files loaded into the editor.
- Various optimizations to speed up loading / unloading (localStorage, Diff, zip compression on the client). Since most of the work is the exchange of data between the client and the server, various measures have been taken to minimize the amount of traffic and, accordingly, to increase the speed of information exchange (which is the narrowest link in the chain).
Differences
The main difference is a two-pane interface with familiar keyboard shortcuts. But that's not all. In contrast to other file managers running in the browser, Cloud Commander has a console and editor.
The editor supports syntax highlighting for more than 110 languages. The file format is determined by its extension. The source code of Cloud Commander is corrected in it (and this article is also written in it).
The console allows you to execute commands on the server, and no matter whether it is Linux, Mac OS or Windows. The server running Cloud Commander is controlled from the console right in the browser.
An important difference is also Node.js as the platform on which the File Manager runs. No more php + apache.
disadvantages
The presence of advantages also implies the existence of disadvantages, without this in any way. The most significant:
- Without node.js, nothing will work.
- If there is no browser with the server, it will be possible to communicate only through HTTP requests.
- With javascript disabled, most of the functionality will not work.
These are fundamental flaws. If we talk about urgent problems, then there are some. In the editor:
- There is a problem with tabs, if not 4 spaces are used, namely tab.
- In the mini opera, everything looks very scary, and the old IE is generally retracted.
- You can not upload / download a folder using Drag'n'Drop (or download several files at once).
- There is no integration with cloud services at the server level (this may well change in the future).
- There is no progress bar when copying / moving / deleting files.
- Uses standard dialog boxes (alert, confirm, prompt).
Composition
As mentioned above, Cloud Commander consists of a client and a server. About the client has been a little said, so let's start, probably from the server.
Server modules
The server can work without the established dependencies, while it goes into the mode of limited operation. In this mode, the console does not work, js / css / html optimizations are not performed, copying, moving and deleting folders does not work. After installing modules written in package.json, use:
- express web server which works much faster than the built-in;
- the minify module, which minifies js / css / html;
- modules for copying, moving, deleting folders;
Common modules
Some modules work both on the client and on the server, this is a diff-match-patch , developed a long time ago, but it works very stably.
Client Modules
On the client, the list of used modules is much wider. It:
Internal organization
Archiver
Most of the questions are probably caused by the archiver on the client. It is used to reduce the size of data sent to the server by the editor. This mode can be enabled (and disabled) in the settings. In fact, as I said, the bottleneck in the client-server application is data transfer. Packing (and unpacking on the server), in turn, is extremely fast.
Diff
But the text does not have to be sent always. It is advantageous to send to the server only the data that has changed, that is, the patch. Therefore, if, between revisions, the file on the server has not changed - a patch is sent and applied on the server (provided that the file does not weigh very much, because each such operation is loading the entire file into RAM), if changed, compressed data is sent . Due to this, the processing speed is very close to the desktop application.
Local storage
Downloading data from the server is also not needed every time you open files. Therefore, when opened (files) are placed in localStorage, in a place with a sha-1 hash. And, if the hash has changed (without our knowledge), the file is loaded again, otherwise the hash is updated each time the file is saved. The same is true of directories. If this option is enabled, the contents of the directory are loaded once, and to update it, press Ctrl + R (or delete / create a new file / folder).
Advanced Module Loading
In such a large application with a huge number of modules, it would be very difficult to figure out if all the files were loaded immediately, when the page was loaded. Such an application would be difficult to maintain, since from time to time some programs are updated, while others become obsolete and require replacement. Therefore, the application is divided into modules: client and server.
Client modules are loaded as needed. If a person needs a menu, it loads, if the console did not come in handy for the entire session, its files did not even load and did not start to run, which significantly increases the speed of work and saves resources both on the client and on the server.
Join
Threads node.js is a very powerful tool that is radically different from what is in other scripting languages. In the process of immersing in node.js, the thought that files can be merged into a stream and given as if it were one file did not leave me. I thought there would be delays in speed, but no. Everything works like a clock, and there are no special slowdowns, but instead, it is possible not to merge files into one, and not to load them sequentially, but to load them as one file .
This idea, from recent times, began to be promoted in jsDelivr . And I think this is the right direction.
In short: if you need to load the jquery.js file and jquery.fancybox.js, you can do it this way:
cloudcmd.jit.su/join/lib/jquery.js:lib/fancybox.jsUsing the ":" symbol, file names are separated from each other, thus, absolutely anything can be combined, and this should not affect the server’s performance, since files are read sequentially, but immediately after reading they are given to the client.
If the file cannot be read, an error message is sent instead, after which the stream closes.
Development
Enough is said about the application itself, but there are a few things that I would like to say about the development. As already mentioned, Cloud Commander is written in itself.
The project is hosted on a githaba . It has two branches: dev and master .
The first is the option that is being developed, all edits are made there, and although ideally everything should always work, sometimes different incidents happen.
In the second branch is the latest stable version. It can always be taken from the repository, everything should be fine with it.
Continuous integration and testing
After each push, the code is sent to the travis.ci system, where the prescribed tests are run, and the code is deployed to NodeJitsu and Heroku.
And if something does not work as it should, the letter immediately arrives, and the icon in the repository changes its color to red.
If, on any of the services, Cloud Commander does not respond, on the site , at the very top, next to the links, not green circles, but red ones are displayed. If the answer is long - yellow.
Task runner
The project uses Gulp , which automates all routine actions: checks js, css, runs tests, etc.
Commits
Once I came across an article that talked about the naming style for commits accepted in Angular. In fact, this is a very important process. Changes, corrections, refactoring, etc. have their own prefix, and during the release, commits with the
feature and fix prefixes are pulled out of the history and displayed in a certain form in the ChangeLog , all this is done by one command: gulp changelog .Afterword
I want to thank the reader for having come so far (even if he just squandered it). I hope the article was useful and interesting. It may be continued, wait and see.
This is my first article on Habré, if there are typos, suggestions, comments - please in a personal or hidden branch in the repository . I will try to correct.
Source: https://habr.com/ru/post/226257/
All Articles