| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
XXX/FIXME:
The console task will BLOCK the tornado, which should be FIXED!
However, the `WebSocket.on_message` currently may NOT be a coroutine
(as of Tornado v4.3), so another way should be taken to solve this
problem in order to call the console task asynchronously!
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* The "tornado.options" can be used in the *global scope*, therefore,
the command line arguments can be stored in the options and then
import the options in other modules if needed.
* Add argument "--hosts-allowed", which specifies the hosts/network can
access the Web UI (i.e., WebSocket)
* Add argument "--no-browser", which controls whether to open the Web UI
in a browser after startup. (TODO)
|
|
|
|
|
|
|
| |
* Source Sans Pro: regular, italic, semibold, semibold italic; WOFF
* Source Code Pro: regular; WOFF
Thanks Adobe!
|
| |
|
| |
|
|
|
|
|
|
|
| |
When the configuration form changed, the changed values are synced to
the server and validated. The validation errors are then sent back to
the client, which set the custom error messages on the corresponding
fields.
|
| |
|
|
|
|
|
|
|
|
| |
* Split out functions "{g,s}etFormConfigSingle()" from
"setConfigForm()";
* Rename original "setConfigForm()" to "setFormConfigs()", and uses
"{g,s}etFormConfigSingle()" to simplify;
* Update other places accordingly.
|
| |
|
|
|
|
|
|
|
|
| |
* Fix the validation for some "input[type=number]" element;
By default, the number type input only accept *integer*. By setting
the 'step="any"' attribute, the float numbers are also valid.
* Add form input validation styles for ":valid" and ":invalid" pseudo
classes.
|
| |
|
| |
|
|
|
|
|
|
| |
* milligram.css: Remove the "sourceMappingURL"
* main.js: Add "use strict";
* utils.py: Add a TODO task
|
|
|
|
|
|
|
|
|
| |
* Rewrite "configs.js" to be more modular and generic
* Bind functions to button click event
* Implement the function to set form fields to given configuration data
* Implement the function to reset server-side configurations
* Implement the function to load user configuration file on server
* Implement get the configuration data from the server
|
| |
|
|
|
|
|
| |
* Update the "logging" property in "manager.py"
* Also add "extragalactic/clusters" to "common/components"
|
|
|
|
|
| |
Replace the filter hack with a cleaner list comprehension.
Be Pythonic :)
|
|
|
|
|
|
|
| |
* Get the server-side configurations as a flattened one-level
dictionary, for easier manipulations.
* When get the configurations, specify the requested config options as
an Array under the "keys" property (original: "data" property).
|
|
|
|
|
|
|
|
| |
* Add helper function "_flatten_dict()" to flatten a nested dictionary
into an one-level dictionary, with the keys are concatenated with a
separator.
* Add a new parameter "flatten" to method "dump()" to allow the dumped
configurations been flattened.
|
|
|
|
|
|
|
| |
NOTE:
Still missing important client-side functions to be usable, e.g.,
set the configuration form according to the received data from the
server, and mark the error states on the fields with invalid values.
|
|
|
|
|
|
|
|
|
|
|
| |
* Improve the response data to be more consistent. If the request
failed, the returned response has "success" item of value "False" and
an "error" item recording the message;
* Add method "_reset_configs()" to handle the "reset" action;
* Add method "_load_configs()" to handle the "load" action;
* Add method "_save_configs()" to handle the "save" action.
NOTE: needs tests.
|
|
|
|
|
|
|
|
| |
All response message has a "success" item indicating whether the request
be successfully handled. If anything unexpected happens, "success" is
False, and an additional "error" item presents recording the detail.
Also add some more stubs which are necessary for the Web UI.
|
|
|
|
|
|
|
| |
Finish the "_set_configs()" function to implement the "set" action
for "_handle_configs()".
Also change the "status" keyword to "success" to be more intuitive.
|
|
|
|
|
|
|
| |
Add internal method "_get_configs()" which implement the "get" action
part of the "_handle_configs()" method.
TODO: implement the "set" action part.
|
| |
|
|
|
|
|
|
| |
* bin/fg21sim: Simplify the "log_stream" assignment
* bin/fg21sim-webui: Also enable debug logging when turning on debug
flag for the tornado; also update the docstring a little.
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Server side:
+ Update the "on_message()" method to support 3 types of message
requests (i.e., "configs", "console", and "results");
+ Add messages stub handlers: "_handle_{configs,console,results}()";
+ Reorder the methods
+ Client side:
+ Change timeout before reconnection to 3000 ms;
+ Parse the received JSON message to JS object;
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
* Rename "validate.py" to "checkers.py", to avoid the confusion with
the "validate" module from "configobj";
* Rename function "validate_configs()" to "check_configs()";
* "check_configs()": add optional parameter "raise_exception";
* "check_configs()": update to return both the result and errors dict.
|
|
|
|
|
|
|
|
|
|
|
| |
The "setn()" method is a corresponding operation with the "getn()",
which set the value of a config option to the given value.
This function will be used in the Web UI to interact with the WebSocket
communications.
Also add the "merge()" method which simply merge the input
configurations without any validation.
|
|
|
|
|
|
|
|
| |
* Remove the optional parameter "sep", therefore the key must be
"/"-separated or a list of keys.
* Add exception handling and raise "KeyError" if the input key is
invalid (i.e., specifies a non-exist option).
* Update comments and docstring.
|
|
|
|
|
|
|
|
| |
Originally, the user configuration file is only allowed to load once,
and prevent any future loading of user configuration file.
This change allows load user configuration file again by resetting the
current configurations to defaults before loading.
|
|
|
|
|
| |
Also add a global variable "ws_reconnect" to control the timeout between
reconnection and the maximum reconnection times (default: 100).
|
|
|
|
|
|
|
| |
FIXME/TODO:
How to determine the WebSocket origin is in the same subnet as the
server? An additional network mask required to determine this.
How does this additional mask passed?
|
| |
|
|
|
|
|
|
| |
NOTE:
This "FG21simWSHandler" is still very preliminary, and there are a
lot of necessary functions need to be implemented.
|
|
|
|
|
|
|
|
| |
* Keep a copy of the default configurations from the specifications
* Add "dump()" method to dump the configurations (as well as the default
configurations) as plain Python dictionary
* Add new parameter "from_default" to methods "get()" and "getn()" to
allow get the config value from the default configurations
|
| |
|
|
|
|
|
| |
Add a label to the header banner to show the WebSocket support status
and connection status.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|