Beautiful Code [181]
$panel->add_track(
-glyph => sub {
my ($feature,$panel) = @_;
return 'box' if $feature->length/$panel->length < 0.05;
return 'gene';
},
-height => 12,
-font2color => 'red',
-label_transcripts => 1,
-label => 1,
-description => 1,
);
Note that the callback arguments for the -glyph option are different from other options because this value is needed before the glyph is created. Instead of passing the feature, option name, and glyph, the callback passes the feature and the panel object.
As it happens, the callback feature became one of the most popular features of Bio::Graphics. As time went on, I added callbacks liberally to other parts of the API, including when processing options passed to the Panel constructor, and in the code that decides in what order to sort features from top to bottom.
On various occasions, users found uses for callbacks that I hadn't anticipated. To give one nice example, I provided a way for users to specify a callback to do some direct drawing on the Panel after it drew its gridlines but before it drew the glyphs. Years later, an enterprising genome biologist figured out how to use this feature to create diagrams that compare the genomes of species whose chromosomes have undergone structural changes relative to one other. The gridline callback draws colored polygons that connect features of one chromosome to the corresponding features in the other (Figure 12-4).
There is also a dark side to the Bio::Graphics::Factory story. In my initial burst of enthusiasm, I added a slew of other features to the option-getting and -setting methods that I omitted from the code examples shown here. One feature was the ability to initialize a factory using a web-style cascading stylesheet. Another feature provided detailed information to each callback concerning the current glyph's relationship to other glyphs in its track or to the top-level glyph. In practice, these features have never been used and are now hanging around as dead code.
Figure 12-4. Clever use of Bio::Graphics callbacks allows related features on two chromosomes to be compared
Growing Beautiful Code in BioPerl > Extending Bio::Graphics
12.3. Extending Bio::Graphics
We'll now look at some of the Bio::Graphics extensions that were added after the initial release. This illustrates how code evolves in response to user input.
12.3.1. Supporting Web Developers
One of the objectives of Bio::Graphics was to support interactive browsable views of the genome using web-based applications. My basic idea for this was that a CGI script would process a fill-out form indicating the genome to browse and a region to display. The script would make the database connection, process the user's request, find the region or regions of interest, pull out the features in the corresponding region, and pass them to Bio::Graphics. Bio::Graphics would render the image, and the CGI script would incorporate this data into an tag for display.
The one thing missing from this picture was the ability to generate an image map for the generated image. An image map is necessary to support the user's ability to click on a glyph and get more information about it. Image maps also make it possible to make tool tips appear when the user mouses over the glyph and to perform such dynamic HTML tasks as populating a pull-down menu when the user right-clicks on the glyph.
To support image map generation, the original version of Bio::Graphics had a single method called boxes(). This returned an array containing the glyph bounding rectangles, the features associated with each glyph, and the glyph objects themselves. To generate an image map, developers had to step through this array and generate the image map HTML manually.
Unfortunately, this was not as