PolyPager has gotten some exciting new features, but the best one allows to work with n:m related data. I explain what that is and show how it will work. 

My little side project, PolyPager, has been waiting for its official 1.0 release for quite a while now. I have been delaying this event for some months now, always releasing so-called 'Release Candidates'. I am working on the fifth by now.

So, one reason for the delay may be that I moved to Amsterdam and started my Masters programme here, things which suck up a lot of time for organisation and completing courses. But also, I have added some cool features in the last months, one of which I want to present today. I think it shows a distinction of PolyPager among other Web Content management systems.

I know that adding features to a release candidate is not good practice, but PolyPager does not exactly have a big community that I owe this to now and I had a good reason: My friend Marcels birthday.

You see, Marcel is a writer. He is trying to make a living writing screenplays. In his head, he always comes up with little ideas about plots, characters, citations and so on. We had always talked about how useful it would be to have a website where he could write these things, no matter where he is and search through them.
But I always dreamed of something more than just a website. I thought that the best feature of his head was that he connects all these little snippets in there. One plot might turn out to be the perfect setting for a character he set up some weeks earlier. That character might also fit well for another plot. These connections should be manageable with PolyPager.

So for his birthday, Jan and I modelled what we thought might resemble Marcels head (Here, a * says that several entities could take part in that end of the relation. So, a Music entity can be used by many plots, but one plot can also use several Music entities):

You see, PolyPager was already able to read Foreign Keys from the database. That means that one field in a table row identifies another row in another table. You could, for instance, have a car save a reference to its current owner (Notice the "1" here. A car can only have one owner):

PolyPager (since version 0.98 I think) will already allow you to select an owner when editing the car and display his name when viewing the car. Fine.
But what if a car has several owners, and people can own several cars? This resembles Marcels situation better. For instance,  a plot can be referencing several characters and characters can be suitable for several plot ideas:

In relational database terms, these relations are called n:m relations and it was some work to make PolyPager able to work with them. In the database, two tables are connected by a third that only saves relations between the two:

In this toy example, Bert and Elmo are referenced for usage in the "bar fight" plot, while Bert and Miss Piggy might end up in the "final kiss" plot (possibly after Bert won the bar fight).

PolyPager will read in the table structure and realize that the plots_characters table connects the plots and the characters table via Foreign Keys. Then, I assumed it might be a good assumption that the first of those tables should be the one from which connections are managed. So, PolyPager will now

  1. Show connections, i.e. "Bert" and "Elmo" when the "bar fight" is displayed, or "final kiss" when "Miss Piggy" is displayed.
  2. On editing a plot, the user can choose which characters should be connected to it.

Here are some screenshots illustrating how that will look in PolyPager 1.0rc5.

Editing a plot. Notice the link box at the bottom. The links can be clicked into the white box or out of it. The data comes from the table that is connected via an m:n table (here, that is characters)

Viewing a plot. The red links show connected characters. Feel free to admire Jan's great design.

This implementation is not a complete implementation of everything you could possibly do with related tables, but I think it is a really useful one. I am looking forward to Marcels experience with it (surely there will be some things to tweak) and I think there are several small projects out there to which this simple tool is really applicable and well-fitting. Any ideas?

That said, PolyPager needs some serious testing by me and Jan before I officially release it as 1.0. I think it is in pretty good shape, but I need to be sure for this important number :-) 


follow comments per RSS     
You are seeing a selection of all entries on this page. See all there are.