Difference between revisions of "Website:Application overview"
Line 67: | Line 67: | ||
The general structure of the application mirrors the organization in Acedb. Separate Model::* packages correspond to classes in Acedb. | The general structure of the application mirrors the organization in Acedb. Separate Model::* packages correspond to classes in Acedb. | ||
+ | |||
+ | |||
+ | ==PAGES== | ||
+ | |||
+ | Pages are composed of widgets. | ||
+ | |||
+ | ===Widgets=== | ||
+ | |||
+ | Widgets are small segments of a page comprised of a series of fields. The widgets available for any page are specified in the primary configuration file. They are comprised of: | ||
+ | |||
+ | * a Controller action named after the widget. | ||
+ | * a template file (if required). | ||
+ | |||
+ | ===Fields=== | ||
+ | |||
+ | Individual sections of each widget are referred to as fields. They are comprised of: | ||
+ | |||
+ | * a Controller method implementing a chained action. This calls a... | ||
+ | * a Model method(s) that collect and massage the appropriate data. The primary method should correspond to the name of the field. | ||
+ | * a template file (if required). The name of the field corresponds to it's section name in the presentation layer. | ||
+ | * field names are: stash keys (dynamic), controller actions (dynamic), template filenames (static), section names in templates. | ||
+ | * fields are also URL and REST targets. | ||
+ | |||
+ | ==EXAMPLE== | ||
+ | |||
+ | http://localhost/gene/*/identification | ||
+ | |||
+ | Access a widget called identification that collects together the fields that comprise the widget. | ||
+ | |||
+ | ==DRAWBACKS OF A COLLECTION OF INDEPENDENT WIDGETS PER PAGE== | ||
+ | |||
+ | Problem: Objects must be fetched for each widget. | ||
+ | |||
+ | Solution: Have a gateway search that redirects to page where widgets are loaded by their ID, or cache the current object the first time it is fetched. | ||
+ | |||
+ | ==ADVANTAGES== | ||
+ | |||
+ | * Each action becomes its own URL target opening up many possibilities for presentation. | ||
+ | * Can I make these REST services, too? | ||
+ | |||
+ | ==IMPLEMENTATION QUESTIONS== | ||
+ | |||
+ | Q: Does it make sense to forward to a chained action? | ||
+ | |||
+ | Q: For customizable data, at which point should display decision be made? | ||
+ | |||
+ | If made prior to fetching data, the code will be faster. If made at the display level, the code is slower but easier caching. (NO!) The caching unit should probably be the actual Perl data structures, not HTMLized data. | ||
+ | |||
+ | |||
+ | ==ABOUT DYNAMIC CREATION OF CONTROLLER ACTIONS== | ||
+ | |||
+ | The following actions are created dynamically from configuration. | ||
+ | |||
+ | - Each widget is a controller method called "name_widget". | ||
+ | |||
+ | - This method is an action chained to /fetch. | ||
+ | |||
+ | - Each field corresponds to a PathPart of a Chained reaction: | ||
+ | |||
+ | sub description : Chained('fetch') PathPart('description') Args(0) { | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | Thus, for basic display, all you need to do is write configuration, and model. | ||
+ | |||
+ | THUS all I need to do is write a list of available data bits, write | ||
+ | the corresponding model, and template! | ||
+ | |||
+ | |||
+ | RENDERING | ||
+ | |||
+ | By default, pages are NOT wrapped by TT. This makes it difficult | ||
+ | to load widgets piecemeal. | ||
+ | |||
+ | |||
== Models == | == Models == |
Revision as of 12:40, 17 January 2008
Contents
- 1 Directory Structure
- 2 Configuration
- 3 Application structure
- 4 Widgets
- 5 Creating new Models and Controllers
Directory Structure
-rw-rw-r-- Changes -rw-rw-r-- Makefile.PL -rw-rw-r-- README drwxrwxr-x build Staging directory for building third party libraries. Current releases should be symlinked to the correct unpacked source. drwxrwxr-x conf Application and third-party library configuration. drwxrwxr-x design Design elements and ideas. drwxrwxr-x extlib Directory containing builds of third party libraries. drwxrwxr-x lib The core application modules. drwxrwxr-x logs drwxrwxr-x private Docs and presentations. drwxrwxr-x root /root contains static files and templates. drwxrwxr-x script Helper scripts and the stand-alone server. drwxrwxr-x sql SQL statements for various databases. drwxrwxr-x src Third party sources. drwxrwxr-x t Application test suite. -rw-rw-rw- wormbase.yml Application-wide default configurations. -rw-rw-r-- wormbase_local.yml.template Template for local configuration. Entries here will override defaults.
Configuration
Catalyst offers a powerful configuration system. We use it to provide application-wide, per-page, and per-session configuration. In addition, local configuration files can be used to override any configuration option for production or development deployment.
Here, $ROOT refers to the document root of your application.
$ROOT/wormbase.yml
This file contains the default configuration for the application. The application defaults to using remote data sources. If you would like to override this, see wormbase_local.yml.
$ROOT/wormbase.yml.template
Move this template file to wormbase_local.yml and edit values to locally override the default configuration variables. This file is maintainted in SVN as a template so that individual development preferences are not obliterated by an inadvertent svn commit.
Application structure
The general structure of the application mirrors the organization in Acedb. Separate Model::* packages correspond to classes in Acedb.
PAGES
Pages are composed of widgets.
Widgets
Widgets are small segments of a page comprised of a series of fields. The widgets available for any page are specified in the primary configuration file. They are comprised of:
- a Controller action named after the widget.
- a template file (if required).
Fields
Individual sections of each widget are referred to as fields. They are comprised of:
- a Controller method implementing a chained action. This calls a...
- a Model method(s) that collect and massage the appropriate data. The primary method should correspond to the name of the field.
- a template file (if required). The name of the field corresponds to it's section name in the presentation layer.
- field names are: stash keys (dynamic), controller actions (dynamic), template filenames (static), section names in templates.
- fields are also URL and REST targets.
EXAMPLE
http://localhost/gene/*/identification
Access a widget called identification that collects together the fields that comprise the widget.
DRAWBACKS OF A COLLECTION OF INDEPENDENT WIDGETS PER PAGE
Problem: Objects must be fetched for each widget.
Solution: Have a gateway search that redirects to page where widgets are loaded by their ID, or cache the current object the first time it is fetched.
ADVANTAGES
- Each action becomes its own URL target opening up many possibilities for presentation.
- Can I make these REST services, too?
IMPLEMENTATION QUESTIONS
Q: Does it make sense to forward to a chained action?
Q: For customizable data, at which point should display decision be made?
If made prior to fetching data, the code will be faster. If made at the display level, the code is slower but easier caching. (NO!) The caching unit should probably be the actual Perl data structures, not HTMLized data.
ABOUT DYNAMIC CREATION OF CONTROLLER ACTIONS
The following actions are created dynamically from configuration.
- Each widget is a controller method called "name_widget".
- This method is an action chained to /fetch.
- Each field corresponds to a PathPart of a Chained reaction:
sub description : Chained('fetch') PathPart('description') Args(0) {
Thus, for basic display, all you need to do is write configuration, and model.
THUS all I need to do is write a list of available data bits, write the corresponding model, and template!
RENDERING
By default, pages are NOT wrapped by TT. This makes it difficult to load widgets piecemeal.
Models
Generic Model methods
Controllers
Generic Controller Actions
Views
Widgets
Widgets are distinct presentation elements of a given model. Widgets correspond to sections in the previous WormBase site. For example, the Gene page has widgets for Identification, Location, and so on.
Specifying configuration
Required Controller actions
Required Model methods
Views
Creating new Models and Controllers
1. Create your new Model or Controller using the wormbase_create.pl script. This script provides stub formatting, documentation, and test files.
$ROOT/scripts/wormbase_create.pl model Test
Creates...
[todd@micos trunk:23]$ ./script/wormbase_create.pl model Test exists "/Users/todd/projects/wormbase/website/trunk/script/../lib/WormBase/Model" exists "/Users/todd/projects/wormbase/website/trunk/script/../t" created "/Users/todd/projects/wormbase/website/trunk/script/../lib/WormBase/Model/Test.pm" created "/Users/todd/projects/wormbase/website/trunk/script/../t/model_Test.t"
2. Add the new files to the SVN repository
svn add lib/WormBase/Model/Test.pm t/model_Test.t svn commit lib/WormBase/Model/Test.pm t/model_Test.t