Location: /modules/EnsEMBL/Web/Magic.pm
Source code · Permalink
No superclasses
No subclasses


EnsEMBL::Web::Magic is the new module which handles script requests, producing the appropriate WebPage objects, where required... There are four exported functions: magic - clean up and logging; stuff - rendering whole pages; carpet - simple redirect handler for old script names; and ingredient - to create partial pages for AJAX inclusions. Three constants defined and exported to the parent scripts... To allow unquoted versions of Gene, Transcript and Location in the parent scripts.



  • Gene
  • Location
  • Server
  • Transcript
  • Variation
  • _access_ok
  • modal_stuff
  • spell
  • timer_push
Documentation coverage: 44 %



    Magically you away through the clouds away from the boring and mundane old existance of your 7 year old 'view' script to the wonderous realms of the magical new Ensembl 2.0 routing based 'action' script.
    Usage use EnsEMBL::Web::Magic; magic carpet Gene 'Summary'

    View source

    We are updating an image config! We are updating a view config!
    View source

    use EnsEMBL::Web::Magic; magic ingredient Gene 'EnsEMBL::Web::Component::Gene::geneview_image'

    Wrapper around a list of components to produce a panel or part thereof - for inclusion via AJAX
    View source


    Postfix for all the magic actions! doesn't really do much! Could potentially be used as a clean up script depending on what the previous scripts do!

    In this case we use it as a way to warn lines to the error log to show what the script has just done!
    Usage use EnsEMBL::Web::Magic; magic stuff

    View source

    use EnsEMBL::Web::Magic; magic menu Gene;

    Wrapper around a list of components to produce a zmenu for inclusion via AJAX
    View source

    use EnsEMBL::Web::Magic; magic mushroom

    AJAX Wrapper around pfetch to access the Mole/Mushroom requests for description
    View source

    Usage use EnsEMBL::Web::Magic; magic stuff

    The stuff that dreams are made of - instead of using separate scripts for each view we now use a 'routing' approach which transmogrifies the URL and separates it into 'species', 'type' and 'action' - giving nice, clean, systematic URLs for handling heirarchical object navigation This block here checks to see if the user has changed the configuration of the page - either by adding a shared URL or, by changing configuration either with a config parameter OR with a "imageconfig" name parameter...
    View source