This post is being written retroactively. I wanted to make sure I marked the point at which I switched over from my old blogging system to this Dropbox powered one. Yup.
When you visit Dropsite, you get prompted to connect your Dropbox account, and
are then given the sole option of choosing a subdomain to setup a "site" on.
From there, a directory is created within your
From there, you simply create files of the following format:
[Title] Dropbox powered website builder [Slug] dropbox-powered-website-builder [Published] March 8th, 2012 10:00PM EDT [Post] ..post..
After your post is done, simply connect to Dropsite, and hit the
Time for the technical :)
This project is running on a LAMP stack, and using the following open source libraries:
There is one database which contains 3 tables. These tables are:
accountsRecords Dropbox accounts
postsRecords posts to a
sitesRecords sites for a specific account (one Dropbox account can have multiple sites)
The 4th table
notifications was added to enable add-on functionality which
emails visitors upon a new post being added.
You can see that it's a pretty basic database setup. I won't go into the columns themselves, but the table definitions are quite basic as well.
site record is created through the Dropsite administration panel, an
API call is made to Dropbox to create a new folder with the site's desired
This then triggers a Dropbox folder to be created for the authenticated user.
After this point, each time the
sync action is triggered through the
administration panel for a site, an API call is made which parses a
specific-site folder, looking for files that have been changed (the markdown
files I demonstrated above).
These files are then checked against the
posts table to see if they are new
posts, or updates to existing posts. The appropriate CRUD operation is
performed, and well, that's about it.
There is a lot of work that gets done with the Dropbox API, naturally, and response handling when certain unexpected behaviour is discovered (eg. Dropbox Mime Types).
Hindsight being 20-20, there are quite a few things I would do differently, and will when I find the time.
At the time of development, the
delta API method was not available. This
method is really efficient when it comes to checking which files should be read
(as in, which ones have changed since a previous
sync call). I would use this
method rather than my current flow, which checks each file's revision stamp to
see if it's been changed.
Additionally, I would decouple a post's title, slug and published timestamp from the post file itself. Rather, I would create a master *.table file, which would act/serve as a traditional RDBMS table which defined post titles, slugs, published timestamps, and add flexibility for post drafts.
They would require a primary key (the first column in the flat-file) of a post file's filename/path.
Finally, I would have templates and the theme (stylesheets) itself pushed to the users Dropbox in order to give them full customization of the markup surrounding their post, as well as the theme.