Update 2009-11-29: Well, I’ve completed some of these plans (see below) and have Wistle back to “good enough” for me, so I’ve decided to forego the rest, at least for the time being. I have looked at migrating to hyde, a fork of jekyll (Jekyll is too “opinionated” for my taste), but have concluded that’s more work than I want for the moment. On the other hand, starting down that path produced an interesting library: svn-transform.

---

So, I’ve been pretty happy with Wistle, the merb app that runs this blog and fromgenesis.org. But I’ve been pondering the future of it. The design is somewhat monolothic, what with several libraries and such just stuck in the lib directory. I’m now thinking about focusing more on the app itself, rather than just the ability to store the articles in Subversion, but the current setup is a bit too interconnected. I would also like to easily re-use several of the bits in the lib directory in other apps.

The driving force here is actually the comments. The views I have so far are not real useful, and there’s no anti-spam measures whatsoever. And as I’ve pondered what I want to do there–and now with some time away from the original work–I’m thinking much more along “this is part of the app (the UI)” versus “this is part of the back end”.

So, refactoring is at hand. I want to strike a useful balance between “trash it and start over” and “make the changes that need to happen” (Although, since its mostly a for-fun project, if I end up trashing a lot, no biggee). I’m considering the best order to approach this; one in which I plan on doing the comments updates last, but at which there are a number of points at which I could stop and jump over to that. So, here goes.

Move to git

Done 6/14/09 - http://github.com/jm81/wistle

Wistle is currently SCM’ed in Subversion. I’d like to move it to git, and host on github. No particular reason, other than for the chance for some more learning. I’ve only done a little bit with git, and since it seems to be ‘the thing’ among the merb/rails folks these days. The little I’ve used it, I’ve liked it…

Libraries to gems

This is where the change really begins. I want to move libraries out to gems, because there’s no reason for these things to be tied to the app. I foresee five gems here:

1. Filters

   Done 7/9/09 - http://github.com/jm81/dm-filters. Unlike with jm81-paginate and jm81-svn-fixture, I did no cleanup on this library, but basically just copy/pasted the code and made it a gem.

   This is the library that allows for filtering text through, e.g. markdown, textile, smartypants, etc. libraries. It will also contain a couple built-in, which I could move out later. One of my favorite features of this lib is the ease of choosing between a variety of implementations for a single filter. For example, for markdown, I could use rdiscount or bluecloth, depending on which is available.

2. Pagination

   (Mostly) Done 6/23/09 - http://github.com/jm81/paginate - See TODO file for future plans for this gem)

   I know, there’s bazillions of pagination approaches out there. This gem would just be for adding a method to DataMapper classes and collections: paginate, which is just like all, but it receives a :page option (and receives or assumes a :limit option). The result has two extra methods: #pages is the number of pages given the current settings, and #current_page is the number of the current page (1-indexed).

   I should probably check what else is out there now, although I’ve never completely liked other implementations I’ve seen, mostly because I want to access the page number and total pages through a method on the returned collection. If there’s something better out there, I probably shouldn’t bother with the updates that are needed, such as adding the #paginate method to DataMapper::Collection.

   What I do have is somewhat based on dm-is-paginated.

3. Pagination-slice

   Update 6/25/09 - I decided this was unneeded. The jm81-paginate gem (above) now has a helper method (Paginate::Helpers::Merb#page_links) that does what I had planned for this slice to do.

   This involves figuring out merb slices, but that’s worth it. I have a helper (might be part of the first library) and a view partial that I use quite a bit, with slight variations. It’s based on someone else’s code, but I’m not sure I remember what.

   Anyway, I think I could create a useful slice, to make this code more easily reusable. I’ll see.

4. Subversion Fixtures

   Done 7/5/09 - http://github.com/jm81/svn-fixture

   Currently in lib/wistle/fixture.rb, this allows a fairly simple way to set up a Subversion repository (which I use in testing the Subversion-to-Datamapper stuff.

5. Subversion-to-Datamapper

   Done 7/10/09 - http://github.com/jm81/dm-svn. As with dm-filters, this gem works, but I haven’t put much effort into it.

   The current lib/wistle directory, the stuff that extends a DataMapper class to allow syncing from a Subversion repository.

(A possible sixth gem has to do with “attachments”, along the lines of attachment_fu. It’s not something currently required in Wistle, but I have one more or less together that works more reasonably to me than other plugins currently available)

New Wistle lib approach

Aside from the fact that the above needs to happen in order to simplify new updates, what really interests me is this part. I want to break up the process in the Subversion-to-Datamapper sync. In short, I want to place an intermediary, which is the Atom Publishing Protocol. That way, I can use Subversion to store and auto-publish to any blog app that accepts Atom publishing. The blog app, then, can also accept from any client that publishes via Atom. Both of these options are appealing to me, while still allowing the Subversion to blog app as it currently is without any change from the perspective of the article writer.

So, there would be two libraries/programs then, such as it is:

• Subversion to Atom
• Atom parser to Ruby model

Ideally, this could go in the opposite direction, so that, for example, I could publish via Atom from Word and it would commit to the Subversion and update the blog app. But I’ve not really investigated Atom to know if this would all be easy enough to be worth it.

Another issue this will create is adding some sort of user privileges to authenticate when users try to post articles, etc.

There will also probably need to be another library for updating the views and public files from Subversion, and (possibly again elsewhere) the methods for allowing the views and assets to be found in the right place in the file system based on which site is currently active.

Update app to new libs

This would actually be an ongoing process, updating the blog app to move from the existing integrated libraries to the new gems, including updating for any modifications to those libraries (which will happen in at least some cases). But at some point, I need to make a concerted effort to ensure this all has happened. Which leads to…

Clear separation of app and libs

By this point, the blog app itself should be a distinct entity. It would accept publishing adds, edits, etc. via Atom Publishing, and use the other libraries as needed. But it would not be tied to Subversion as the storage mechanism, and the gem could be used in other applications.

Update versions of datamapper and merb

Another thing that will need to happen, and I’m not sure when, is to update to the latest and greatest datamapper and merb versions, and the latest svn-client lib, which does have some changes. But those will need to happen at some point, at this if not before.

Fix comments

Hey, now we get to really fix the comments, because there’s not all that other stuff in the way. Obviously, this could happen sooner. It involves two major pieces:

1. Nicer looking default views.

2. Anti-spam. I’m currently looking at reCAPTCHA. Another possibility I’ve considered is that the first time a visitor posts a comment using a given email, they would receive a validation email. Since I have no intention of actually showing commenters’ emails, this should be workable.

   Update 7/6/09 - Minimal work to add recaptcha support. Commit

General app cleanup

Because, there will be stuff to clean up, right?

As a final comment, if anyone else is interested in working on this, please let me know: jmorgan at morgancreative dot net. I don’t know that this project would hold any interest for anyone else, but it would be silly of me not to ask, eh?