A Backbone.js + jQuery Mobile app for accessing the Wormbase database through its RESTful API.
. ├── index.html ├── config.xml ├── css │ ├── images ├── images ├── js │ ├── collections │ ├── libs │ ├── mobile.js │ ├── models │ ├── routers │ └── views └── templates ├── app └── classes
Libraries and dependencies
- Backbone.js to aid application structure, routing
- Underscore.js for templating and other utilities
- Require.js for modular separation of components
- Require.js Text Plugin to enable external templates
- jQueryMobile + jQuery for DOM manipulation, mobile helpers
- Backbone Fetch Cache - modified by me - https://github.com/antonio0/backbone-fetch-cache - used for the purpose of caching of recently viewed elements. My fork allows to keep track of when cache records have been created and last accessed.
- Spin.js - http://fgnass.github.io/spin.js/ - to make the spinners inside Widget Boxes
- Pluralization JS library - http://oranlooney.com/js-plural/
Note: This application needs to be run on a HTTP server in order to use external templates.
Use of WormBase REST API
Widgets are requested in text/html format, the response goes through an "enhancer" function which adapts all the links to work within the mobile application, then a few changes to the DOM of each Widget are made in order to make them responsive and improve performance on mobile devices.
For widgets whose structure on mobile devices would need to be implemented in a radically different way, there is the possibility of creating a custom widget by putting a template file into the templates folder (e.g. templates/classes/gene/overview.html). In this case the Widget is requested in JSON format and its fields are available within the template using a 'fields' identifier.
The App follows a variation of the Model View Controller design pattern. As in all Backbone.js applications, there is no controller because the logic that operates the app is in the View.
The components of the app are the following.
A comprehensive list of all the possible routes that have been implemented so far can be found on the Router page.
Collections can be thought as list of models. They also handle fetching of data from the server. The collections in use are:
- Widget Collection - represents a list of widgets
- Search Results Collection - a list of results for a search
- Search Types Collection - this represents the list of options for the search dropdown menu
- Resource Types Collection - represents the list of resource types returned by the API(e.g. Laboratories, Papers, ...)
- Species Collection - represents the species list as returned by the API. Further parsing of this list is defined in the view(s) that make use of it (in order to extract Genus list, species list and the list of available classes per specie)
Models for this application are:
- Object - it represents a Wormbase object, identified by a class and a WormBase ID. Each object is associated with a Widget Collection
- Widget - it represents a widget, it handles fetching of the widget data from the API. Its 'parent' property must be the Widget Collection this widget belongs to.
- SearchResultEntry - it represents a single search result item.
Views handle the logic of the app. Each view is associated with a DOM element (some are pages, others are sub-elements of them) and a Model or a Collection. They can be seen as nested elements each of those handling input/output for some part of a web page:
App View |-- Home View |-- History View |-- Search Page View |------ Search Results View |---------- Search Result Entry View |-- Object View |------ Widgets Panel View |------ Widgets Area View |---------- Widget View |-- Browse Species View |-- Browse Resources View |-- Filtered Search View |------ Search Results View |---------- Search Result Entry View |-- About View
As soon as Backbone gets initialised, a "WBMobile" object gets added to the browser's "window" object.
WBMobile is used in order to keep references to:
* views: a reference to AppView and all other views which directly represent a page (such as HomeView, ObjectView, etc.). References to views which don't represent a page (like WidgetView) shouldn't be kept here in order to avoid name conflicts when a view is used in more than one page (example: Search Results View is used in both Search Page View and Filtered Search View). * routers: in this app there is only one. * utils: no need to load our own 'utils' library through require.js on each view that makes use of it * defaults: some default strings / objects / settings that are often used within the app
App Packages are compiled using the service PhoneGap Build. Those packages can be found here: https://build.phonegap.com/apps/544268/builds
The config.xml file has the purpose of defining the parameters that the Cordova compiler will use to generate app packages, such as the name of the app, its description, icon, screen orientation, external access whitelist and much more. Beware that some of this settings may also be platform specific. For a complete list, refer to the PhoneGap developer documetation, http://docs.phonegap.com/en/3.0.0/config_ref_index.md.html#Configuration%20Reference