Web interface

The web based interface has many benefits and implements additional functionality. The main features of the web interface:

• are the ability to run semantic queries- both of global queries and queries starting with @ are supported,
• the query construct assistant,
• the query storage and the visualisation of the query result,
• possibility to see running queries and abort them if necessary,
• database operations,
• ability to mark files with error forms,
• dependency examinations.

JavaScript must be enabled in the browser to be able to use the interface!

Installation

To be able to use the web based interface we need to have an already working Yaws webserver. Required version is 1.89. Help for the installation: ​http://yaws.hyber.org/yaws.pdf (Chapter 2).

Start up

We can start the interface either with referl script with -nitrogen switch, or from RefactorErl shell. In both cases we get a default configuration with server name localhost, port 8001, and IP 127.0.0.1.

Starting up with referl script

Parameters to be configured:

• -yaws path YPATH: The absolute location of your Yaws ebin directory.
• -yaws listen YLISTEN: Valid IP address, which Yaws will listen to.
• -yaws name YNAME: Valid domain name, which Yaws will be bound to.
• -yaws port YPORT: Valid port number, which Yaws will be bound to.
• -browser root BROOT: The web based interface allows database operations. The root directory for those operations can be set, by giving the path of root directory in this parameter.
• -images dir IDIR: Path of the directory where the generated images, which are the visualisation of the results of dependency examinations, will be written.

Usage of switches is optional, except the -nitrogen switch.

Example:

 bin/referl -nitrogen 
            -yaws_path /Users/V/yaws-1.89/ebin 
            -yaws_listen 127.0.0.1
            -yaws_port 8000
            -yaws_name localhost
            -browser_root /Users/V/erlang
            -images_dir /Users/V/graph_images

Starting up from RefactorErl shell

We have 2 functions for starting the interface : ri:start nitrogen/0 and ri:start nitrogen/1. If the 0 arity function is used, the interface starts up with default configuration. If the 1 arity function is used the start up can be configured using a prop-list. Available properties are the same as described in the previous section. Usage of switches is optional. Example:

ri:start_nitrogen([
    {yaws_path,"/Users/V/yaws-1.89/ebin"},
    {yaws_listen,"127.0.0.1"},
    {yaws_name, localhost},
    {yaws_port,"8000"},
    {browser_root,"/Users/V/erlang"},
    {images_dir,"/Users/V/graph_images"}]).

Shutting down

It is important to log out, before shutting down the interface, because the log out process will delete the dynamic generated images, which belong to the user. If the interface have been started up from RefactorErl shell, then ri:stop nitrogen(). can be called to shut down the interface.

Logging in

To log in one must open a browser (recommended: Mozilla Firefox, Google Chrome) and enter the URL defined by the configuration (the default is http://localhost:8001/) after the web server had been started. Usage of services are allowed only to authorized people. First, you have to log in with a username (passwords are not supported yet). The browser will be redirected to queries page.

Semantic queries

This service is available under ”Queries” menu.

Constructing semantic queries

The query construct assistant is located at the top-left corner of the page. While typing into the text-box, the interface offers possible continuations for the actual, uncompleted sub-term. The offered option can be chosen from a drop-down list. This auto-complete mechanism helps new RefactorErl users to use the language, and also all developers to speed up query construction and to avoid constructing wrong queries.

Pressing the ”Run” button evaluates the query and displays the result.

Position based queries

A file browser is placed at the left side of ’Queries’ page at ’File browser’ tab. One of the previously loaded files can be opened in text view from the file browser panel, by clicking on the magnifying glass icon after selecting a file. By selecting a region or pointing at a position in the text- box, where the contents of the file are loaded in, one can specify the exact position as starting point. Also the result of the previous query can still be reused as a starting point.

Node based queries

Previously loaded files can also be opened in links view from the file browser panel, by clicking the link icon after selecting a file. In this view queries can be started from a specific node. You can select a node by clicking on it (only text in bold can be selected). The selected node will be marked with red color.
After selecting a node you can either:

• Run pre-defined queries for that node from the top-right corner of the screen.
• Run previously made queries for that node type by selecting one from the Choose previous query dropdown box.
• Run a query from the query construct assistant text-box, which will start from that node.

The first result of the query will be shown (if there was any). Results can be browsed with the appearing Prev and Next buttons. The total number of results as well as the currently shown result's number are displayed under those buttons.

NOTE: This feature is still under development, and does not support every query. Please use the Position based queries when you need more explicit results.

Global queries

If the Global queries checkbox is checked, all queries run from the query construct assistant text-box will work as in text view (and not starting from the selected node). This setting is only important when browsing a file in links view, and a node is currently selected.

Alias-able queries

We made queries alias-able, cause of named queries can be identified easier, and are more readable for humans, too.

After a query has been successfully run first, it appears at the left side of ’Queries’ page at ’Previous Queries’ tab.

By clicking the corresponding ’E’ button, a text-field appears, which contains the query string. By replacing the query string with the name, what is wanted to assign to the query, and clicking the ’Save’ button the query will be named. After a name has been assigned to the query, the name appears at ’Previous Queries’ tab instead of the query string. If the name of the query should be changed, the same mechanism should be done as described above.

The query string can be shown as an information element by clicking the ’?’ button.

Previous Queries

For your convenience, the interface stores previously exe- cuted queries and their results, which are listed at the left side of the page at ”Previous Queries” tab. One can choose to list only the queries which belong to the current user, or all the queries stored in the system.

When one of the queries located in the list is clicked on, the interface first examines if the database has changed since that given query was last run. If there are no changes, the stored result is displayed. In the other case, the query is re-executed, the stored result is updated, and the new result is displayed.

Users have possibility to delete their own queries from the list by clicking on the corresponding ”X” icon, or to run queries which belong to other users by clicking on the query string.

By clicking on the corresponding ”?” icon, the query string and previously added comments are always shown. If query is one of the queries with @ the starting file and position are also shown.

By clicking on the corresponding ”E” icon, one can assign or can reassign a name to the query. This mechanism helps users to identify queries much easier. Users can add comments, either on their own queries, either on the queries of the others, too. By clicking on the corresponding ”C” icon, one can modify the previously added comment. By default, the comment field is empty.

Running Queries

The list of currently running queries is displayed at the left side of the page at ”Running Queries” tab. The list is updated in every second. A running query,which has been started by the current user, can be aborted by pressing the corresponding X icon. The current user, who started the query, is notified about the success of the abort.

Displaying the result of queries

Results are displayed at the left side of the page at ”Last Result” tab in a table. The source of the entries of the result’s can be visualised by clicking on the given entry in the detail. If the source is loaded to the database, it will be shown in a text-box located to the right of the table. The part of the source code responsible for the entry will be highlighted in the text-box.

Skeleton of queries

Large amount of queries are similar to each-other. The difference usually originates from the actual value of their filter parameter or from the used sub-query. Examples are shown below.

mods[name = a].funs[(name = f) and (arity = 2)].refs 
mods[name = b].funs[(name = g) and (arity = 3)].refs

or

mods.funs[arity = 2] 
mods.funs[exported and is_tail_rec]

A new abstract level is introduced, where those queries are not only similar to each-other, but those queries do equal to each-other, we called it Skeleton. Examples are shown below.

mods[name = $ModName$].funs[name = $FunName$ and arity = $Arity$].refs
mods.funs[$FunSubQuery$]

Usage of the skeleton

The service of the skeletons is available under ’Queries’ menu. A skeleton can be constructed by typing its body, which observes the rules of the valid skeleton, into the query construct assistant, than ’Save as skeleton’ button should be pressed. By pressing the ’Save as skeleton’ button, a dialogue box appears, where the wanted name of the constructed skeleton should be typed. By clicking the ’Save’ button, which is placed in the dialogue box, the skeleton will be saved. The constructed skeleton appears in the list of available skeletons, which is located at the ’Skeletons’ tab, whether the save was success. If any error occurs during the save, an error message will be shown.

A previously saved skeleton can be evaluated by calling as a function with the actual values of the parameters. A valid actual parameter can contain nearly anything, only the ’ character is needed to avoid, because the ’ character is the delimiter of the value of an actual parameter. Auto-complete does not only offer the possible endings, but also does offer the joint skeletons.

A valid skeleton call is shown below:

Name = skeleton_name
Body = mods.funs[$FunSubQuery$]
skeleton_name(’ (arity>0) and (name like s) ’).

Previously saved skeletons are listed at ’Skeletons’ tab.

By clicking the name of the skeleton, a valid ’skeleton call’ will be placed in the query construct assistant, where the actual parameters should be written by replacing character with the corresponding parameter value.

By clicking the ? icon, the body of the skeleton and the owner of the skeleton will be shown.

After a successful evaluation of a skeleton, the generated semantic query string and its result are saved in the ’Previous queries’ list, and the result of the semantic query will be shown in the right side of the page.

Only the owner of the skeleton can edit its body, or can delete it.

By clicking the corresponding ’E’ icon, the body of the skeleton will be placed into the query construct assistant. After the necessary changes had been made then the ’Update skeleton’ button has been pressed, the body of the skeleton will be updated.

By clicking the corresponding ’X’ icon, the skeleton will be deleted.