My coding work lately has focused on a major upgrade to Planeteria by giving it a web framework (currently it has none).  The framework I chose was Flask, because of its simplicity, its flexibility, and its scalability.  It has a strong community and documentation, which makes our project more friendly to new contributors, and has several add-ons for features that we hope to implement/improve upon for the site down the road, which will make future improvements to the site much easier.  I’ve also done some reorganizing of the files so that there’s clearer separation of the business logic and presentation logic.  Again, this should make the site more friendly to new contributors who might want to edit the backend Python code without unintentionally altering the page content.  The page layout is in Bootstrap, which is another tool that is commonly used and well documented.  It’s often used by developers for prototyping, with some handy defaults for buttons, blocks of text, etc.   Although you may notice that many projects and websites that have a very similar look because of this, it provides a foundation that is very easy to alter through CSS that a skilled designer could do a lot more with.

This week I created a schema for the data in SQLite3 and did a crash-course in SQLAlchemy to work with that data.  Currently, Planeteria stores its data in sqlite with the help of a tiny tool that simply stashes it as if it’s a dictionary;  there is no schema.  This has been a huge frustration of mine, as it’s difficult to see exactly what data is stored in what format.  Not ideal when trying to debug Unicode issues and character escaping.

I now have planet data (name/description/slug) and a planet’s feed data (feed name/url/image/planet id) saving to a database, with the ability for a planet admin to update any of that data correctly.  With just a few sql commands, I can now check the database and see if my code did what it should with the data.  Huzzah!  This led to a few revisions of the schema, each time simply deleting the database and creating a new one with the updated schema, then more testing.  Last night, I did some rigorous testing, trying my hardest to “break” it (identify flaws).  The biggest test was using unicode characters and quotes; two things that cause problems right now if they’re entered in the admin page.  It saved and loaded the data exactly as it should!  It’s lovely when things just work as they’re supposed to.

The database does not yet save feed content data.  It’s still to be determined exactly how that will be saved.  I’ve talked before about adding tagging to the site to help people more easily identify content within a planet that is relevant to them.  Since the only users on the site are the planet admins, the planet admin would be responsible for assigning tags to each feed; but how would the admin correctly guess what tags would most interest the planet readers?  I think it just puts an undue burden on the planet admin for maintaining all the tags for their planet feed.  Additionally, admins can edit a blog’s feed data but they have no control over individual blog entries; the topics discussed by a blogger in the planet might vary greatly, making an individual tag that brings up that blogger’s entries only applicable to some, not all of those entries.

I’m not sure that adding individual user logins for readers to save personally selected tags is the right solution.  It seems overly complicated and potentially underused.  I’d want to wait to see if there is really demand for this; as it is, many readers are simply reading the feed in their own feed readers anyway.  A much simpler solution that would enable readers to find content most relevant to their interests is a Search window.

I bring all of this up because how the feed content data is used/accessed will guide the decision of how it’s saved.   A relational database would be an appropriate way to store feed tags, but if we want users to be able to search the content, storing it in a server designed for searching such as Solr or Elasticsearch might be more appropriate.

While I mull that over, there are plenty of other things to do with the Admin page functionality I’ve built so far: next on my plate is form validation, security, and error reporting.  Then, adding user logins, most likely with Mozilla Persona.

WFS Planet update:  Today, I updated a few feeds in the Women in Free Software admin page and was reminded again of a bug that makes feed images disappear or assigns them to a different person’s feed.  I’ve put those images back where they should go for now, but it may happen again.  It pains me to leave the live site in its broken state, but I’ve decided to focus my efforts on the Flask implementation instead and create a stronger foundation so that bugs like this can more easily be avoided in the future.  I’ve made sure that the javascript on the new admin page assigns unique ID’s to each feed’s data so that this can’t happen on the new Admin page once the Flask site is launched.  I can’t wait to see it in action!

Advertisements