Docendo discimus


  • Calendar

    May 2017
    M T W T F S S
    « Sep    
  • Archives

  • Recent Posts

  • Bling

Posts Tagged ‘references’

Vedalken reborn (in Alara)

Posted by brunorc on May 9, 2010

I planned to later update the Vedalken’s database with the contents of Gatherer, the official database of Magic cards, run by Wizards of the Coast. However, I discovered that the content scraped from Essential Magic was not good enough – probably because I was parsing comma separated list, which was a part of JavaScript function call. Moreover I discovered that some basic lands still made it to get to the database. And finally, I started to check how to scrape the Gatherer just to find that there’s no easy way to get the given card just by its name. The only unique identifier in Gatherer is the multiverse ID. Frankly, one card may have many multiverse IDs, because every time it gets printed in a different edition, new multiverse ID is assigned.

Because of all those issues I decided to start again from scratch – even if I already put all my non-basic lands and colorless spells in the database. I can always use this information and just do UPDATE… so I renamed the table (that was very good move, as it occurred later) and started almost from scratch.

This time I wanted to isolate the code into functions to make the flow clear and understandable. Here’s the top part of the script:

#!/usr/bin/env perl

use strict;
use warnings;

use WWW::Mechanize;
use HTML::TreeBuilder;
use DBI;

my %cards;

my $mech = WWW::Mechanize->new;
my $BASE_URL = "";

my $dbh;
my $sth;

scan_set( $_, \%cards, $mech )
    foreach get_sets($mech);

print scalar keys %cards, " unique cards found\n";

scan_card( $_, $cards{$_}, $mech )
    foreach keys %cards;


There’s a new module – HTML::TreeBuilder, part of HTML::Tree suite – which is necessary to parse HTML in a little bit more advanced way than it’s possible with WWW::Mechanize only. The logic is separated into three functions: get_sets (providing a list of all sets, since cards will be searched by set names), scan_set (updating the global hash with info about cards from the particular set) and scan_card (fetching to the DB block of HTML code with card description). At the end of run I should have raw HTML for each card stored in the database, so I can parse it and update detailed information later. Another advantage is that I don’t have to make final decisions about the data model, just focusing on the scraping part.

I only define my database-related variables without any initialization – I will discuss it later, since it had really interesting effects.

The first function takes the $mech object as an argument and returns the list of sets (fetched from Essential Magic, as before), processed by the next function:

sub get_sets {
    my $browser = shift;
    my @sets;


    my $tree = HTML::TreeBuilder->new_from_content( $browser->content );

    my $link_check = sub {
         $_[0]->attr('href') =~ m!CardSets/Overview!;

    foreach my $class ( qw/Row1 Row2/ ) {
        my @rows = $tree->look_down( '_tag' => 'td', 'class' => $class );

        foreach my $row ( @rows ) {
            if ( my $link = $row->look_down(  '_tag' => 'a', $link_check ) ) {
                ( my $id = $link->attr('href') ) =~ s/^.+ID=//;

                    if grep { $id == $_ } qw/1 23 30 32 53/;

                $sets[$id] = $row->look_down( '_tag' => 'img' )->attr('alt');
                # fix differences
                $sets[$id] =~ s/Timeshifted/"Timeshifted"/;
                $sets[$id] =~ s/WorldWake/Worldwake/;
                $sets[$id] =~ s/10th/Tenth/;
                $sets[$id] =~ s/9th/Ninth/;
                $sets[$id] =~ s/8th/Eighth/;
                $sets[$id] =~ s/7th/Seventh/;
                $sets[$id] =~ s/6th/Sixth/;
                $sets[$id] =~ s/5th/Fifth/;
                $sets[$id] =~ s/4th/Fourth/;
                $sets[$id] =~ s/Portal-/Portal/;
                $sets[$id] =~ s/.*Starter 1999.*/Starter 1999/;
    return reverse grep { defned $_ } @sets;

In this function HTML::TreeBuilder is used to find particular elements of HTML code. In line 14 I want to get all <td> tags of the given class. However, in line 17 beside passing a list of parameters specifying tag type or attributes, I also use the $link_check variable. This variable is in fact a reference to an anonymous function. The function itself is defined in line 9. The documentation for look_down function shows an example where the anonymous function is passed directly in the call, but since the look_down is called in the if clause, I wanted to make the code shorter. Anyway, instead or beside of parameter => value pairs, one can pass a reference to a function, which would return true or false (indicating if the condition was met). I was only interested in links, where href parameter was matching some specific pattern. In case of WWW::Mechanize I could have used something like this:

my @links = $mech->find_all_links( url_regex => qr{CardSets/Overview} );

but HTML::TreeBuilder only allows simple comparisons. In fact, everything else can be put in a function, so it’s a good deal.

All matching links have to be prepared and stored. Preparation include removing everything from the beginning, so only the ID of the set is left. I’m not particularly interested in those IDs, but they will make the list organized. Also, I want to skip some of them. Then I use the alternate text (since sets are indicated in the table using images…) and fix it in case of some sets; at the end I return the reversed list of all sets. The list is reversed, because I want to have cards with their latest multiverse IDs (for example Glory Seeker was recently reprinted in the Rise of the Eldrazi, but its first version appeared in Onslaught).

Once the list is ready (and undefined values are filtered out by grep), it is passed to the foreach loop, where every item will be processed by the scan_set function:

sub scan_set {
    my ( $set_name, $cards_href, $browser ) = @_;
    print "Processing set \"$set_name\" ";

    my $set_url = "%s/Search/Default.aspx?output=checklist&action=advanced&set=[%%22%s%%22]";

    $browser->get( sprintf( $set_url, $BASE_URL, $set_name ) );

    my $tree = HTML::TreeBuilder->new_from_content( $browser->content );

    my @rows = $tree->look_down( '_tag' => 'tr', 'class' => 'cardItem' );
    print " - ", scalar @rows, " cards found\n";

    foreach my $row ( @rows ) {
        my $link = $row->look_down( '_tag' => 'a', 'class' => 'nameLink' );

        my $name = $link->as_text;

            if grep { $name eq $_ } qw/Plains Forest Swamp Island Mountain/;

        ( my $id = $link->attr('href') ) =~ s/^.*multiverseid=//;

        if ( exists $cards_href->{$name} ) {
            push @{ $cards_href->{$name}{gids} }, $id;
        else {
            $cards_href->{$name} = {
                gid     => $id,
                gids    => [ $id ],

The first argument of this function is the set name, and the third one is a “browser” (WWW::Mechanize object). The second one is passed in the call as \%cards. Again, it’s a reference – but this time it’s a reference to a hash (usually called a “hashref”). Usage of the reference allows one to pass arguments by reference (quite surprising, right?), instead of passing them by value:

my @list = qw/foo bar baz/;

sub by_val {
    my @args = @_;

    foreach (@args) {
        $_ = uc $_;

sub by_ref {
    ( my $args ) = @_;

    foreach (@$args) {
        $_ = uc $_;

print join( ', ', @list ), $/;

print join( ', ', @list ), $/;

The first function receives a list of arguments passed by their values and stores them in the @args list. But in fact they are copied, one by one, and the function operates only on those copies. That’s why changes are not stored in the original (elements of @list are not converted to upper case). The latter function receives one argument – which is the reference to the list (references are denoted by the backslash before the original variable). In the foreach loop it has to be dereferenced, so Perl will use the object pointed by the reference and treat is like an array.

Actually, the same effect can be achieved by using the original argument list:

sub by_direct {
    foreach (@_) {
        $_ = uc $_;

since accessing arguments like $_[0], $_[1] will also allow to modify the original passed value. But naming arguments is always a good idea; also passing by reference is the only way to pass complex data structures to a function.

sub scan_card {
    my ( $cardname, $storage, $browser ) = @_;

    my $card_url = "%s/Card/Details.aspx?multiverseid=%d";

    $browser->get( sprintf( $card_url, $BASE_URL, $storage->{gid} ) );

    my $tree = HTML::TreeBuilder->new_from_content( $browser->content );

    $storage->{raw} = ( $tree->look_down( '_tag' => 'div', 'class' => 'smallGreyMono' ) )[1];

    $storage->{gids} = join( ', ', @{ $storage->{gids} } );

    $sth->execute( $cardname, @{$storage}{ qw/gid gids raw/ } );

Since $storage is a reference to a hash, instead of using $storage{something} the arrow notation is used: $storage->{something}. Also, the “gids” field contains a reference to an array, created in line 30 of the scan_set function, and dereferenced in line 25 of the same function, to have push being called on it. Here, in line 12 it’s dereferenced in the same way. And in line 14 I want to pass the values of three fields to the function call; instead of writing every single one like $storage->{gid} and so on, I use hash slices. If the $storage was an ordinary hash, I could write @storage{ ... }, but since it’s a reference, I have to dereference it: @{ $storage }{ ... }.

Perl is very flexible in treating data structures according to the programmer’s will. In the line 10 I call the look_down function, which – when called in so called “list context” – returns a list of objects matching the given conditions. In scalar context it returns the first element found. But I’m interested in the second one… thus I call the function in the list context, I treat the whole call as a list and return only the second object of this “list”.

Last but not least I had to initialize my DB-related variables. I put them on the bottom of the file in the BEGIN block. Those named blocks are quite useful, but I used the wrong one. The problem is, the BEGIN blocks (since there may be more than one) are executed in the compilation phase. So when I ran perl -c (to check if there are no stupid syntax errors), this code got executed. Luckily, there was no DROP TABLE IF EXISTS, and moreover I renamed the already populated table. But actually I wanted this code to initialize my variables, so I should have used the INIT block (or use the $COMPILING variable to check if the code is compiled or run, but that would be completely wrong).

# used to be BEGIN...
    $dbh = DBI->connect( "dbi:SQLite:dbname=vedalken.db", "", "" )
        or die "Cannot open or create the DB file: $DBI::errstr";

    $dbh->do( q/
            id      INTEGER PRIMARY KEY,
            name    VARCHAR(64) UNIQUE NOT NULL,
            gid     INTEGER NOT NULL,
            gids    TEXT,
            raw     TEXT
    / ) or die "Cannot create table: ", $dbh->errstr;

    $sth = $dbh->prepare( q/
        INSERT INTO Card (name, gid, gids, raw)
        VALUES (?, ?, ?, ?)
    / ) or die "Cannot prepare insert statement: ", $dbh->errstr;

Of course every BEGIN or INIT block is still just a block, so any variable defined inside its scope will not be visible or accessible from outside. Thus $dbh and $sth had to be defined beforehand, in the global scope (because closures would be an overkill).

Anyway – I ended up with the database populated with raw HTML scraped from Gatherer (10961 cards). Next time I plan to use HTML::TreeBuilder to parse it and fill the data model.

Posted in Perl | Tagged: , , , , , , | 1 Comment »

Catalyst is easy – third movement

Posted by brunorc on June 27, 2009

Wherever you go to read about Catalyst you will find it is an MVC framework. But we are still digging in the same file, aren’t we? Everything the application does is stuffed into one controller file. Now we are going to change it and isolate the model.

Model is responsible for providing the data. Very often it will be some database wrapping module, but data can be fetched from everywhere: filesystem, mail queue, IMAP, LDAP, Web Service, image generator/transformator, version control system, RSS feed… However, model shouldn’t be identified with the data itself. All the facilities – like formatting or consistency checks – should be done inside the model, not in the application. Then the model can be reused while writing e.g. maintenance scripts. Actually, Catalyst model classes should only act as a glue code between the application and the real model, which shouldn’t be related with Catalyst.

In our case the data consists of one list, but recently we isolated some code used for adding new items. We can put this code in the separate module and use all model-related facilities of Catalyst. Of course, we need a model for this:

script/ model Simple

and the stub of the model will be created in the file lib/helloworld/Model/ The file itself is not very interesting, since all the necessary code is inherited from Catalyst::Model class.

We would like our model to access the “raw data” (in this case – the list), to return all items, to add a new one and maybe to do the search. Let’s start with =cutting the documentation under the description and putting some stubs:

package helloworld::Model::Simple;

use strict;
use warnings;
use parent 'Catalyst::Model';

=head1 NAME

helloworld::Model::Simple - Catalyst Model


Catalyst Model.


my @raw_data = qw/beer bacon pierogi/;

sub get_all {
  my ( $self ) = @_;

  return @raw_data;

sub add_new {
  my ( $self, @newitems ) = @_;

  push @raw_data, @newitems;

Notice that methods of the model don’t have access to the Catalyst context object, because, in fact, they shouldn’t have it.

Now we can check how it works. Until now, the code in the index action looked like this:

sub index :Path :Args(0) {
    my ( $self, $c ) = @_;

    my $list = '';

    foreach my $item ( @list ) {
        $list .= "<li>$item</li>\n";
# (...)

Let’s change line 6 of this example:

    foreach my $item ( $c->model('Simple')->get_all ) {

Similarly, we can change this line of the _add action:

    push @items, @new_items;

to this:


Why bother? Let’s assume that there’s a need to have a unique list of items. It can be achieved easily, converting the array into the hash, without changing a single line in the controller. This is the code of the new version of the model:

my %raw_data = map { $_ => 1 } qw/beer bacon pierogi/;

sub get_all {
  my ( $self ) = @_;

  return keys %raw_data;

sub add_new {
  my ( $self, @newitems ) = @_;

  $raw_data{$_} = 1 foreach @newitems;

Now it is possible to move the code from the private action to the model. However, there’s no $c variable received by model methods. And since there’s no context, there will be no possibility to populate the stash directly. No problem at all:

$c->stash->{add_result} = $c->model('Simple')->add_new($whatever);

But how to stuff the message and count in one variable? Oh, and probably we would like to notify user – just in case – that he tried to add the value already present in the list. Returning the hash reference allows one to pass anything necessary. This may be not the best option, but at least it gives some reason to mention complex data structures.

After this, the controller will look like this:

sub api_add :Local :Args(1) {
    my ( $self, $c, $newitem ) = @_;

    if ( $c->req->method eq 'POST' ) {
        $c->stash->{add_result} = $c->model('Simple')->add_new($newitem);

        $c->res->body( $c->stash->{add_result}->{count} ? "OK" : "ER" );
    else {

sub add :Local :Args(0) {
    my ( $self, $c ) = @_;

    my $optional;

    if ( $c->req->params->{newitem} ) {
        $c->stash->{add_result} = $c->model('Simple')->add_new( $c->req->params->{newitem} );

        if ( $c->req->params->{addit} eq 'Add it!' and $c->stash->{add_result}->{count} ) {
            my $count = $c->stash->{add_result}->{count};
            $optional = "<h4>Thank you for adding $count items!</h4>";

        if ( $c->stash->{add_result}->{message} ) {
            $optional .= '<h4>' . $c->stash->{add_result}->{message} . '</h4>';
    # template part skipped

All the logic is now embedded into the model class:

sub add_new {
  my ( $self, $newitem ) = @_;

  my $result = {};

  if ( $newitem =~ s/_//g ) {
      $result->{message} = 'Removed illegal underscore(s). ';

  my @newitems = split / /, $newitem;

  my @okitems = grep { not exists $raw_data{$_} } @newitems;
  $raw_data{$_} = 1 foreach @okitems;

  $result->{count} = @okitems;

  $result->{message} .= 'Skipped ' . ( @newitems - @okitems ) . ' doubles'
    if scalar @newitems != scalar @okitems;

  return $result;

but why to put the result in the stash? At the moment it is used only internally, but in fact, stash is the way to propagate the information from Model into View. The application has no view yet, but soon it will change. Generating HTML inside the code is clumsy and once we get tired of it, Catalyst is eager to relieve us of this ugliness.

Posted in Catalyst for intimidated | Tagged: , , , , , , | 1 Comment »