From: Paul H. <pau...@gm...> - 2008-05-30 18:33:48
|
Wow, great feedback everyone. I'm very grateful for all of your insights and opinions on this new feature. Let me sort through some of the responses and make some comments. First of all, you have all correctly identified the problem of terminology, which is definitely something we need to sort out in order to be able to talk about this in a way that makes sense. I think Chad has the right idea when he talks about this feature as an extension of both comments and tags. I think the most intuitive way to think about this project is *not* as adding a whole new *type* of extra data but rather as adding support for a new *relationship* between certain existing forms of extra data and specific regions of an image. - Flickr: "note" --> *comment* + *region* - Facebook: "tag" --> *tag* + *region* Gallery already has fairly solid support for both comments and tags, so let's use what we've built. I think the most elegant way to handle this new feature would be to have it add the ability to associate a region of an image with other Extra Data modules (within reason--looking at the list of modules I'm thinking tags, comments, and maybe custom fields). So when the feature is active, your tags and comments can also be mapped to specific regions of an image if you so choose. I agree with Andy that a monolithic Tags module is incompatible with the Gallery Philosophy. But... > On the other hand, there's no module-dependency framework yet. If we > want to avoid code and functionality duplication, a "image annotation" > module would need to depend on the "tags" module to reuse its tag > cloud, tag storage, tag albums, etc. > > Say a user wants the "image annotation" feature, the framework should > figure out that it depends on the "tags" module in version x.y and > install the tags module in the background. > > But we're not there yet. Andy's right that a module dependency framework is what would be most useful here. The "Image Region Support" (badass name pending) module as I'm picturing it needs to interact with other modules that may or may not be installed and may be of varying versions. But we don't necessarily *need* a full MDF--we can just have the new module check what it needs to check. This is more or less Andy's solution (B): > B) Identify the parts in the tags module that can be reused (API, tag > cloud, tag album, etc.), refactor them slightly such that they can be > exposed via an API / factory implementation / block and reuse them > from your module. Add some code in the module's needsConfiguration() / > autoConfigure() method to verify that the tags module is installed and > active. This is the direction in which I'm planning to start working. > Remember: The tags module still needs to be moved to the official > codebase. It still needs some cleanup and tests. If we can identify a list of things that need to be done, I might be able to take care of this along the way. Thanks again everyone, and keep the comments/thoughts/$0.02 rolling in! Paul |