I've become moderately intrigued by the notion of a generic drop handler. This would be a useful component for a document management system or to perform some other interesting task with dropped files (for instance, you could use it to send faxes or something). And I know, roughly, how to go about handling drop events from an active app.

It turns out that drop handling in the Windows environment -- on the desktop or from the SendTo folder -- is a horse of a different color. You have to write a shell extension and do a lot of Registry work. Which makes it a nice, compact project, and I started the research today.

A drop handler is registered against a file extension. These extensions are not generally the mere three-letter things used for actual files, but longer descriptive names, because they're not intended for use with actual files. Instead, you create zero-length files with these magical extensions, and those place a convenient icon somewhere in the Explorer (like the SendTo menu).

My drop handler will act on an XML file which encodes a wftk action (or something along those lines), at least potentially. It should also be possible to do without the wftk for general purposes; my initial demo will be a neat utility idea I purloined from the forum at The Software Jedi's place -- it will allow the registration of files in a list with keywords, and the keywords will then be used to format a tag cloud like the ones you can see e.g. at del.icio.us. That's a fun little application of a neat UI trick which won't get in the way of the actual point of the exercise, which is the drop handling itself.

The goal is implementation and documentation within a week. Let's see how I do.

There are two general ways to approach software design; each has its uses.

Top-down design looks at the entire project and breaks it into high-level components; those components are then subprojects and can be further handled in the same way.

Bottom-up design looks at the resources available and sees likely things that can be done with them; the idea is to provide generalized components to be used in any project.

A healthy software design ecology has a lot of bottom-up components at varying stages of maturity; those components then inform the top-down requirements of the current project, giving those designs something to work with. In the absense of complex components, we're forced to write everything from scratch, and it all turns into ad-hockery of the worst kind.

Anyway, that item of philosophy out of the way, I wanted to talk about the design of this week's project, the drop tagger. There are three main components of the drop tagger, as follows:

• The drop handler
  The drop handler is the component which interacts with the shell and provides something you can drop files onto or otherwise tag them. It calls the file manager. However, the notion of a general drop handler is a much more interesting one than a special-purpose drop handler just for this project, and one which can be a valuable addition to many different file-oriented projects.
• The file manager
  The file manager shows us what files have been dropped, allows us to add and delete them and modify their tags, and for fresh drops it will actively ask for tags. It also calls the tag cloud formatter and provides a convenient place to display the cloud.
• The cloud formatter
  This is likely to be the least general and thus the least interesting of these components, but it formats the file cloud upon request based on information compiled about the tags in the system.

Each of these components can be designed and used in isolation, and reused in other projects. Alternatively, once we've defined the components we need to meet our goal, we may well be able to find ready-made components already available (or at least something we can adapt instead of starting from scratch). There is then a maturity effect over the course of multiple projects, as our codebase allows us to be faster and faster responding to the need for a project.

I'd like to formalize this design process over the course of several mini-projects. Stay tuned for further progress.

Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content Read content