GMOD

GBrowse Program Structure

This page gives a basic overview of how GBrowse has been organized and programmed, and is intended for developers to get a feel for the structure of the program so they can become more comfortable adding features to it or modifying it for their own needs. Help is always available via the mailing list, or on other sections of the GMOD wiki.

Contents

Program Structure

GBrowse is split into two parts, an HTML/CSS/Javascript frontend and a Perl backend.

The backend is built as a series of modules in the Bio::Graphics::Browser2 package, it acts as a convenient, graphical, front-end to using the Bio::Graphics library. Bio::Graphics can load libraries of features on a genome and render images to display sections of the genome showing those features, but it can only be called via a Perl script or larger program. GBrowse automates the calling process and gives it a GUI so that more data (or a different section of the genome) can be requested by clicking a button. In addition to the backend, there is an optional database to hold named users & sessions, uploaded files, and sharing information.

The frontend is a set of Javascript and CSS files which determine the look and feel, as well as the control events, of the GUI. The main HTML is rendered through the Perl CGI module and simply returned as the HTTP request; there’s no formal HTML file that determines the markup. Each section of HTML has a subroutine in Render\HTML.pm that will generate it.

The AJAX Pipeline

Some Javascript events require data from the database, or need to perform actions on the database. For the most part, they will send AJAX requests to the current script with an “action” parameter. This gets sent through to Action.pm, which calls the corresponding function (so an action of “update_coordinates” will call the ACTION_update_coordinates() subroutine), and performs whatever it needs to do. Most functions will be called and the corresponding sections of the HTML will be re-rendered and updated with update_sections() rather than send back individual values to be processed and inserted by Javascript.

Normal Operations

Most operations go through the gbrowse script, included in the cgi-bin. For each request, the script creates a new Browser2.pm object, opens the globals, then creates a new HTML.pm object and runs the run() function (inherited from Render). Render->run() is what controls the main page – it will send actions to Action.pm, rendering requests to HTML.pm, etc.

Render acts as a central hub for the program, it creates the objects which act as interfaces to the various parts of the program. UserTracks.pm controls the custom data the user can upload, Session.pm works with the current user’s session, I18n.pm controls the internationalization, etc. All of these objects are initialized by Render.pm and can be accessed through it.

Some objects also need to be constructed outside of Render.pm; things like UserDB.pm, which deals with registered users, are called through another script, gbrowse_login, which doesn’t go through the work of creating a whole new Render object.

Modules

The modules which make up GBrowse are contained in the lib directory in the SVN. They are as follows:

State Information

There are a few variables available internally which describe three levels of the current “state” of GBrowse. The are as follows:

Globals

Globals is a Browser2.pm object, and it loads information pertaining to the state of Gbrowse’s setup on the computer it’s running in from the Gbrowse.conf file and stores it in easily-accessible methods. It doesn’t change between users or page reloads. A full description of what each setting does can be found at <configuration file page>.

Session

Session is a Browser2::Session object, and it keeps user-specific information that is to be kept for every time the user logs in, such as the username, whether or not it’s private, the plugin settings, and a copy of the state (as described below.)

State

The state or page settings object is the current “state” of the browser for the specific user – which tracks are on/off, added/removed, etc. It contains mainly user interface settings, things that would not heavily interfere with a user’s experience if they couldn’t be retrieved for whatever reason.

Categories:

Documentation

Community

Tools