view release on metacpan or  search on metacpan

lib/Maypole/Manual/Flox.pod  view on Meta::CPAN

=head1 NAME

Maypole::Manual::Flox - Flox: A Free Social Networking Site

=head1 DESCRIPTION

Friendster, Tribe, and now Google's Orkut - it seems like in early 2004,
everyone wanted to be a social networking site. At the time, I was too
busy to be a social networking site, as I was working on my own project
at the time - Maypole. However, I realised that if I could implement a
social networking system using Maypole, then Maypole could probably do
anything.

I'd already decided there was room for a free, open-source networking
site, and then Peter Sergeant came up with the hook - localizing it to
universities and societies, and tying in meet-ups with restaurant
bookings. I called it Flox, partially because it flocks people together
and partially because it's localised for my home town of Oxford and its
university student population.

Flox is still in, uh, flux, but it does the essentials. We're going to
see how it was put together, and how the techniques shown in the
L<Request Cookbook|Maypole::Manual::Cookbook> can help to
create a sophisticated web
application. Of course, I didn't have this manual available at the time,
so it took a bit longer than it should have done...

=head2 Mapping the concepts

Any Maypole application should start with two things: a database schema,
and some idea of what the pages involved are going to look like.
Usually, these pages will be displaying or editing some element
of the database, so these two concepts should come hand in hand.

When I started looking at social networking sites, I began by
identifying the concepts which were going to make up the tables of the
application. At its most basic, a site like Orkut or Flox has two
distinct concepts: a user, and a connection between two users.
Additionally, there's the idea of an invitation to a new user, which can
be extended, accepted, declined or ignored. These three will make up the
key tables; there are an extra two tables in Flox, but they're
essentially enumerations that are a bit easier to edit: each user has an
affiliation to a particular college or department, and a status in the
university. (Undergraduate, graduate, and so on.)

For this first run-through, we're going to ignore the ideas of societies
and communities, and end up with a schema like so:

    CREATE TABLE user (
        id int not null auto_increment primary key,
        first_name varchar(50),
        last_name varchar(50),
        email varchar(255),
        profile text,
        password varchar(255),
        affiliation int,
        unistatus int,
        status ENUM("real", "invitee"),
        photo blob,
        photo_type varchar(30)
    );

    CREATE TABLE connection (
        id int not null auto_increment primary key,
        from_user int,
        to_user int,
        status ENUM("offered", "confirmed")
    );