For some time, in the context of my workflow toolkit, I've been thinking intensively about UI design in wxPython.
See, once I was embroiled in a rather extensive project developing a GUI application under wxPython, and frankly, the UI was unmanageable. It had been developed with some IDE tool or another, but the output was Python code. It was horrible, trying to find what was what and on which panel it was developed and what its ID was -- ugh! This was back in about 2001.
At that point, I hadn't really started integrating wftk into Python yet, but I dabbled in it over the next couple of years, always with the notion that the UI is most sensibly defined in XML, and that a sensible UI manager would then take that definition and build all the objects needed to implement it in wxPython (or, for instance, online in a portal or something). And since that time, other people have naturally had many of the same ideas, and you see this implemented. But I've always wanted to finish my own implementation.
The current app for Anappaweek.com that I'm working on is, of course, a GUI app (at least, some of the time.) And so naturally I have relived my need for my UI design notion -- and in the context of working on the file tagger, I intend to start implementing the UI module. On that note, here is a tentative UI definition sketch for the file tagger. Ideally, we could use this XML not only to generate the app itself, but also to generate documentation for the UI design (by transforming it with XSLT into SVG, for instance; wouldn't that be indescribably cool?)
All of this is, of course, subject to radical change. Here goes:
<frame> <tabset> <tab label="Cloud"> <html> </tab> <tab label="Files"> <splitter (some kind of parameters)> <panel> <radio-group> <radio value="something" label="All"/> <radio value="something" label="Some"/> </radio-group> <listbox/> <button label="Show"/> </panel> <listcontrol> <col label="Name"/> <col label="Tags"/> <col label="Description"/> </listcontrol> </tab> </tabset> </frame>
I already have a framework for that definition to go into -- I wrote that in, like, 2002 or so. But I never got further than definition of menus. So here, I'm going to implement frames, and at least one dialog.
Note that what's utterly missing from this is any reference to code to handle events. That will come later, when I see what has to be defined where to get all this to work.
And on that note, I close.
I never really officially released wftk 1.0, of course (the magnitude of the task simply grew and grew and I became less and less certain of my approach -- and then the recession happened.) But I've been thinking a lot of a more reasoned approach lately, and maybe it's time to reboot the wftk project and start more or less "from scratch".
I see the modules in this new approach more or less as the following:
And there you have it -- my plan to wrap up the thought and work of eight years. Oh, and this time I'm not bothering with licensing requirements. Like SQLite, wftk 2.0 will be in the public domain. I don't really care if I get credit or not for every little thing, because frankly, anybody who counts will figure it out. And have you noticed how everything these days uses SQLite? It's because -- well, primarily because it works, but also because you don't have to worry about legal repercussions of using the code.
That's where wftk document management should be, where wftk workflow should be. Simple, easy to use, and ubiquitous.
Something that a lot of my project ideas have in common lately is a kind of generalized document management framework.
This isn't as impressive as it sounds, actually. But it's kind of a key notion for Web 2.0 stuff -- if you want collaboration, you have to have a place to store that collaborated content. That place is the document management system.
Let's consider this for a moment, in the context of the fantasy name generator from last week. That fascinating little thing takes a simple document -- the language definition -- and runs a Perl script on it, yielding some interesting results. The Toon-o-Matic does the same thing; it takes a simple XML document and runs a whole sheaf of Perl on it to generate an image. A Wiki for my general site content, or a forum, or even a simple Web form post, can all be seen as doing the same thing. An online programming tool; same thing. All these systems share a component -- the user can submit a large (ish) text object, often based on an existing one, for arbitrary processing, which usually has some visible effect on the system.
If you just look at that little unit of functionality, you can imagine lots of attractive ways to extend it, too. As I mentioned in my initial post on the fantasy namer, you can suddenly imagine allowing people to name a particular definition. You can imagine a page devoted to it, perhaps including all the results it's generated -- maybe in ranked order. All that's a lot of different features, but the central one is simply being able to store and manipulate that central document. It provides a hook on which you can start hanging interaction; without the hook you can't even conceive of where to start.
So this notion's been in my head lately. Oh, I'm sure all this was done in much more diligent detail ten years ago. (Well. Seven or eight years ago, anyway.) In fact, I can think of a couple of systems -- but they're all too damned complicated. What I'm after is the ability to boil these things down to their essence, to provide a language of thought about these systems. For myself, anyway. Assuming you exist, you may or may not benefit. (But I'll bet you would.)
A tutorial approach to workflow -- right here!
So for the last month or so I've been working on rewriting the wftk from the ground up, in Perl, with proper object orientation (which is to say, given it's Perl, just enough object orientation to let me not trip over my feet, but not so much that it makes me crazy).
When I started my casual redevelopment, it was because I had discovered Term::Shell, which is brilliant for casual development of code where you're really not quite sure what you want to do with it. Just start writing, and develop new commands as they occur to. Cycle often. This worked great for the current version of WWW:Modbot (available on CPAN, but not very well-documented yet, because I got sidetracked on the wftk, you see).
Anyway, I got quite a ways in before I realized I was starting to break things I'd done earlier. So I did something I'd never done before, but had always intended to: I reorganized the entire project to use test-driven development. Each new set of features or "featurelets" is in a subsection of a tutorial. I write a new section of the tutorial, making up the code as I think it should work, copy that code into a new test section, and run "make test". Then I fix it.
So all of my development is fixing. I'm good at fixing.
You can see the current state of the Perl tutorial over here. I've started with data manipulation as per my blog post last year about how the wftk should be structured. It's going slowly because there's just so much functionality that needs to be in there -- but every day, I do a little subsection, and I feel a sense of accomplishment.
This is a sweet library. You can define lists with a natural syntax, add data with a copy command or by throwing lists and hashes at it, then query it all with SQL. It's everything I had always thought should be in the (data) repository manager, but didn't have the time to write, because in Perl, half of everything is already there and waiting for you on CPAN.
I'm going to start blogging each major point finished, just to continue to give myself a feeling of accomplishment, and also to provide a little bit of timeline for myself looking back. This project has been running for about two months already; it'll probably take a year, at least, perhaps more -- so it's going to be fruitful to look back and see what I finished when.
So I had this really, really stupid idea a couple of days ago, but I just can't shake it. See, I'm rewriting the wftk in Perl in tutorial form, something that I've planned for a really long time.
Well, here's the thing. The Muse picked Perl, essentially because WWW::Modbot is an OOification of the original modbot stuff I wrote in Perl. And the Term::Shell approach to the modbot turned out to resonate so well with what I wanted to do, that I just ... transitioned straight from the modbot back to wftk in the same framework. But Perl -- even though I love Perl -- is not something I'm utterly wedded to, you know?
And now, I'm working in a unit-testing paradigm for the development. I've carefully defined the API in each subsection, tested it, and know where I'm going.
So here's the stupid idea. It just won't let go of me. Why stick to Perl?
Why not take each class, each unit test, and do that in selected other languages? It would be a fascinating look at comparative programming between the languages, wouldn't it? And the whole point of the wftk is not to be restrictive when it comes to your existing infrastructure -- wouldn't one facet of that unrestrictiveness be an ability to run native in Python? Ruby? Java? C? Tcl? LISP?
It just won't let go.