Dynamic Content

For most users, it will be sufficient to use plugins in public-plugins/mirror to modify existing pages. This has the advantage of leaving the Ensembl code in modules intact. Currently the Object/Factory/Configuration are pluggable but most other scripts are not. Hopefully EnsEMBL/Web/UserConfig.pm will be pluggable in late 2006/ early 2007.

Using Plugins

Here we use extending synteny view as an example of using Plugins to extend the standard Ensembl web page

  1. First, add or edit the configuration module to add in the extra panel by calling your plugin (e.g. 'MyExtension'):

      package EnsEMBL::MyExtension::Configuration::Chromosome;
      use strict;
      use EnsEMBL::Web::Configuration;
      our @ISA = qw( EnsEMBL::Web::Configuration );
    
    
      sub syntenyview {
        my $self = shift;
        if( $TP = $self->{page}->content->panel( "info$self->{flag}" ) ) {
          $TP->add_component_last(qw(
           syteny EnsEMBL::MyExtension::Component::Chromosome::syteny_links
          ));
        }
      }
      1;
      
  2. Create a new namespace for your plugins, e.g. public-plugins/myextension/modules/EnsEMBL/MyExtension
  3. Then add the additional component in your own "MyExtension" plugin.

      package EnsEMBL::MyExtension::Component::Chromosome;
      use strict;
    
      sub synteny_links {
        my( $panel, $obj ) = @_;
        $synteny_info = $obj->_get_synteny_stats();
        $HTML = '' ; ## munge $synteny_info into HTML....
        $panel->add_row( 'SyntenyView', $HTML );
      }
      1;
      
  4. Add the function call to a plugin object
      package EnsEMBL::Development::Object::Server;
      use strict;
      use EnsEMBL::Web::Object;
      our @ISA = qw(EnsEMBL::Web::Object);
    
      sub _get_synteny_stats {
        my $self = shift;
        my $ensembl_object = $self->Obj;
        my %synteny_info = ();
        ## get synteny info....
        return \%synteny_info;
      }
      1;
      

Note: At the moment the drawing code is not plugable. So to extend the zmenu you would have to patch the appropriate drawing code track. We are working on a z-menu solution using AJAX

Extending an Ensembl Class

  1. Create a new namespace for your plugins, e.g. public-plugins/myextension/modules/EnsEMBL/MyExtension
  2. Create your module that inherets from EnsEMBL::Web::Component, e.g. .../EnsEMBL/MyExtension/Component/Gene.pm
  3. Create the 'Configuration' module for the 'Component', e.g. .../EnsEMBL/MyExtension/Configuration/Gene.pm
  4. Use the 'Configuration' module to use your 'Component', e.g.
      # MyExtension-specific GeneView configuration.
      sub geneview{
        my $self   = shift;
        my $document = $self->{page};
        my $content  = $document->content;
    
        # Top (Gene) Panel
        my $panel = $content->panel('info0');
        $panel->replace_component
            qw( name EnsEMBL::MyExtension::Component::Gene::name );
      }
    
  5. Edit the $ENSROOT/conf/Plugins.pm file so your plugins get used;
        $SiteDefs::ENSEMBL_PLUGINS =
         [ 'EnsEMBL::MyExtension'   =>
            $SiteDefs::ENSEMBL_SERVERROOT.'public-plugins/myextension' ]
       

    This means the directory gets added to the perl library path below the default 'modules' directory. Any perl modules that you add will therefore be used in preference to the default ones. This holds for API modules as well as web ones.

Coding a new Dynamic Page

As in the previous version of Ensembl, standard dynamic pages are created via a 'view' script in /perl/default, e.g. geneview. However the modules used by this script have been reorganised.

To create a totally new dynamic page you need to create 5 Perl files:

The view script will need to be created for each view, but the other modules may already exist. If so, you will need to add your own subroutine to the configuration module and probably make some minor changes to the component module.

View Script
In the case of many views, this can be copied from a similar 'new view' and tweaked to reflect the script name and data object type of your view.
Factory module
This will use a lot of the same code as the old DataFactory::[datatype]Factory module, but will need some tweaking - compare an existing Factory child module with its DataFactory version for the main changes.
Object module
This will use a lot of the same code as the old Data::[datatype] module, especially the subroutines. The first few lines, e.g. 'use' statements, should of course be adapted from a similar Object child module.
Configuration module
This module doesn't have an equivalent in the old code, but its structure is very straightforward and should be easy to copy from a similar config module.
Component module
This will use a lot of the same output code as the old Renderer::[datatype]::HTML module, but will probably need a fair amount of tweaking, of both the Perl and HTML, to match the new object model and XHTML style.