Uses for Copland
As part of my on-going preparations for my RubyConf, I’ve been trying to actually use Copland for various projects. This has proven quite educational, in many ways—for one, I’ve identified areas of improvement for Copland, but I’ve also learned more about the application of IoC/DI.
Packrat, I’ve mentioned before (here). Although almost too small of a project to really benefit from IoC, it nevertheless was a good exercise, and will hopefully be a good learning aid for people wanting to use Copland.
Another experiment, Joplin, was an attempt to see how well IoC would work to support a database abstraction layer, like DBI. I may come back to this one and flesh it out more eventually-it showed a lot of promise-but it would have required a lot more work than I had time for to create components for the more commonly-used databases. One thing that I really liked about this particular project was that it was much easier to create hooks for new databases than it is with DBI. Still, DBI has a large following in the Ruby community, and I don’t know that I’m up to the challenge of competing with it.
My most recent experiment is called Faure, and is an object-relational mapping layer. There are already plenty of such projects in the community (ActiveRecord being one of the most popular, currently), there are things about all of them that I don’t particularly like. Besides which, if I can get both Joplin and Faure working smoothly, I’d have half of a complete front-to-back web-application solution implemented around Copland! And that’s pretty attractive to me.
The last piece to create, in that case, would be the presentation half. Hypothetically speaking, if I were to write such a thing, I would probably base it on Tapestry, since I’m reasonably familiar with that architecture, and there are many things about it that I like.
Speaking purely hypothetically, of course. I’ve got far too much to do right now.
