Milestone Reached - Development::Framework Complete
Progress!! The first milestone on building this new site for board gamers has been completed at last.
For those that have been following the progress of FastMovingGames and read the website development plan I posted a week ago, then you’ll know that building a site like this requires a significant amount of technical development and programming to achieve.
(For New Visitors, FastMovingGames is a new online service for board gamers that I’m developing - Read more about the vision here)
Dynamic Websites
There are different types of websites: many sites contain simple information or are information resources - developing these are easy since once the content is written, it rarely changes.
Building something like FMG requires a lot more effort - the pages require more smarts, intelligent logic, dynamically generated content based on what people are entering, and storing game and system state into a database so next time you come visit, the site can remember you.
The Framework
So how to set up a site like this? Not easily is the answer! Luckily I’ve been doing this for a number of years now, so I’ve got a good head start.
It’d be great if you could jump straight into building each of the final pages that will appear on the site. This is certainly one way to do it, but you’d quickly find you’d end up repeating yourself and either copy-pasting or rewriting blocks of web code like managing the user’s logon details, validating form fields, and sending emails for example. This could get very messy when you make a mistake or need to update something - you’d suddenly have to make these changes across all those pages already written!
So, it makes sense to build a re-usable framework which contains all of these common things that are shared across most or all pages. That’s exactly what I’ve been working on over the last few weeks. The real value of doing this work now is it’s not just reusable across FMG, but I’ve structured the framework to reusable across any future websites I build!
What’s in the Framework
Good question! If you’re new to building websites, all you need to know is that making sites like this work requires a lot of complexity behind-the-scenes. I’ve provided a summary of what I’ve built into this framework below to give you more of an idea.
For those with a real technical mind, I’ve attached a visual overview of what’s in the framework to give you an insight into how the framework interacts with the main application. If you don’t understand this sort of diagram, skip over to the non-techie discussion of what this means!
The Techie-Version
The Non-Techie Version!
- Application Configuration
- This part of the framework deals with all of the common configuration needed by the various pages such as database passwords, default email address, file locations, and more.
- Database Connectivity
- All of the information users enter and is displayed back needs to be stored so that it can be remembered next time the user comes to the site.
- A shared way of getting data in and out of this database is useful to provide a single point of reference - this is what this part of the infrastructure does.
- Email Notifications
- The website will generate a number of emails. Whether these are game notifications or simply password reminders, I need a simple and reusable mechanism to send HTML and plain text emails with a common look and feel.
- Using a standard design method, I’ve separated the logic of the email sending engine to the actual display (or ‘rendering’) of those emails, allowing easy editing of the content without having to get stuck into any code.
- Given the unreliable nature of email with bounces and failed deliveries, I’ve also built a reliable mail queue mechanism to allow failed emails to be retried and resent efficiently.
- Error Logging and Handling
- Wouldn’t it be nice if a website never had any problems! Nice dream. Even with a thorough testing phase, building web software like this can lead to all sorts of unforeseen problems due to the massive complexity of the underlying code.
- This module therefore allows errors to be captured with sufficient information that I can determine why the problem occurred, where to fix it, and how; showing a nice error page to you instead of filling the screen with garbled technical information from the underlying programming language - eugh!
- I’ve built a number of different notification mechanisms so that errors can be logged to a zipped log file on the server; summarised and output to screen whilst I’m developing; and finally for when I launch, email me any critical errors that need looking at pronto!
- Session and Login Handling
- Thinking ahead, the majority of the web pages on the site will require you to login before you can access them - mainly because they’ll be personal to you and store information relating to your usage of the site so need to be secure.
- Managing persistent information across web pages and even after you’ve shut down your browser is possible by using web sessions and ‘cookies’ - these are little files that are stored on your computer by the web browser so that we can figure out who you are next time you visit the site.
- This part of the infrastructure, therefore, deals with managing your session, authenticating you across page requests to ensure you stay logged in, and handling the ability to remember your login after you’ve shut down your web browser.
- Forms Validation
- Web servers can and will be hacked - mainly through mis-using forms on the website to send unexpected data to exploit the web server or database into doing unexpected, and often, malicious things.
- Pre-empting this sort of activity and checking what people are entering into forms before you use that data to send emails or add stuff to the database is good practice.
- This module adds a number of different reusable form validation routines such as checking required fields, field lengths, types, doing comparisons, and checking email addresses.
- Application Setup
- Finally, after building all this infrastructure, we need a way to setup and configure all these various components that need to interact on a web page.
- The application module therefore setups the application: loads the config; initialises the database connection; configures and install the session manager; and prepares to receive errors.
- The final step of setting up the application is determining how to handle the request for a particular page and dispatching to an appropriate page handler (e.g the login page, home page, game search page etc.)
- Page Rendering
- The actual page rendering becomes really easy thanks to all of the infrastructure and configuration.
- Each page is made up of two components: form submit logic; and a template to display the actual page (much like I described for the email above) - again this makes it easy to change the displayed page or the logic behind each page.
Where Next?
So that’s it, all built in my spare time over the last few weeks! It’s complete as much as I can initially foresee, so now I can actually start using it to build the functionality of this board games website!
Next step is to start working on the games module, and rewrite the existing board games pages into something more useful, searchable, and tying in to the actual functionality of the site!
Stay tuned for the next milestone.
-Dan
Add Your Comment