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

Maypole::Manual::Flox Ranking & Summary

Maypole::Manual::Flox Tags

social networking Perl module Maypole manual Flox manual Flox

Maypole::Manual::Flox Description

Maypole::Manual::Flox - Flox: A Free Social Networking Site. Maypole::Manual::Flox - Flox: A Free Social Networking Site.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 Request 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...Mapping the conceptsAny 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") ); CREATE TABLE invitation ( id char(32) not null primary key, issuer int, recipient int, expires date );Plus the definition of our two auxiliary tables: CREATE TABLE affiliation ( id int not null auto_increment primary key, name varchar(255) ); CREATE TABLE unistatus ( id int not null auto_increment primary key, name varchar(255) );Notice that, for simplicity, invitations and friendship connections are quite similar: they are extended from one user to another. This means that people who haven't accepted an invite yet still have a place in the user table, with a different status. Similarly, a connection between users can be offered, and when it is accepted, its status is changed to "confirmed" and a reciprocal relationship put in place.We also have some idea, based on what we want to happen, of what pages and actions we're going to define. Leaving the user aside for the moment, we want an action which extends an invitation from the current user to a new user. We want a page the new user can go to in order to accept that invitation. Similarly, we want an action which offers a friendship connection to an existing user, and a page the user can go to to accept or reject it. This gives us five pages so far: invitation/issue invitation/accept user/befriend connection/accept connection/rejectNotice that the befriend action is performed on a user, not a connection. This is distinct from invitation/issue because when befriending, we have a real user on the system that we want to do something to. This makes sense if you think of it in terms of object oriented programming - we could say Flox::Connection->create(to => $user)but it's clearer to say $user->befriendSimilarly, we could say Flox::User->create({ ... })->issue_invitation_tobut it's clearer to say Flox::Invitation->issue( to => Flox::User->create({ ... }) )because it more accurately reflects the principal subject and object of these actions.Returning to look at the user class, we want to be able to view a user's profile, edit one's own profile, set up the profile for the first time, upload pictures and display pictures. We also need to handle the concepts of logging in and logging out.As usual, though, we'll start with a handler class which sets up the database: package Flox; use Maypole::Application; Flox->setup("dbi:mysql:flox"); Flox->config->display_tables(]); 1;Very simple, as these things are meant to be. Now let's build on it. Requirements: · Perl

Maypole::Manual::Flox Related Software