Model Discussion
Discussion of the new object model from the forums
Alex Wilson
Last night I was able to get some simple tag stuff working. As I have it, pictures have tags, and I extended the image class to show the tags for a picture. Adding the tags through the interface (right now I was testing them by adding them to the database directly) will come next, but since it will behave very much like the image description code, the interface part should be pretty easy.
As for tagging/keywords/taxonomy/folksonomy, some reading to start: http://neosmart.net/blog/2007/the-need-for-creating-tag-standards/
So, out of curiosity, what would people like to see in a zenphoto tagging system? There are a couple design choices I would think need to be made, depending on what people really want/need: -Space or commas to separate tags? Something configurable? (This seems like a little thing, but depending how configurable the code has to be does affect its complexity) -Limited character set? This could be useful in that tag-based URLs would be meaningful. -Flat, bundles (like del.icio.us), full tree hierarchy of tags, or something configurable? If not flat, can tags be duplicated and still be the same tag, or are they different? Are the non-leaf nodes searchable and visible to the site viewers, or are they just or organise the tagging process?
Heya Tristan,
I know you've been busy with 1.0.8, but when you get a chance:
I've been able to implement a new tagset class -- given one or more tags, it returns just the images with all those tags. I've got pretty much full end-to-end pieces in place, from class-tagset.php, to changes in the controller and template functions through to a new template page representing the browse-by-tag page: Enough that I can put in a URL of /gallery/tagset/tag1%20tag2 and get back a page listing the filenames of the images tagged with both tag1 and tag2.
My sticking point now is the Image class -- as it stands, I believe it needs to be created with a populated Album object, which I don't currently have in this album-free context. I could create one, I think, but that seems like a fair bit of extra overhead if it's not needed. Given the current roadmap, is that likely to change? It seems that for Groups, Dynamic Folders, search results, etc., you'll want to be able to create Images without creating the album.
I don't want to go in a vastly different direction here, since that would make future integration, if desired, much more difficult. For now, I'll try creating an Album object and see if that does the trick.
trisweb
Ah, but your images will have albums technically, since they will still always reside in folders, so semantically it still makes sense--
What would make more sense is for Albums to be a subclass of Group, and Tagset to also be a subclass of Group, then for an image to be a member of a Group instead of an Album. Then you could have images in albums explicitly, or in Tagsets, or in Searches, or whatever.
This would, I believe, have some consequences for the Image class as you say. First, the Image needs to store the whole path to itself, independent of the group it happens to belong to. Not too hard.
I think that's the ideal solution, and something for 1.1 or 1.2. I like where that's going, it would add a whole new level of flexibility to the already flexible Zenphoto. :-) I will do it that way, as far as I know now, so you can go ahead and instantiate Album objects in your code now just to get the whole path, with the idea that you may get rid of them later when that's all contained in an Image.
Cool :-) Thanks for helping me think that through.
And of course I'll be wanting to look at your code when you're done :-)
Extensible groups... heh, I love the idea. Think of all the ways you could combine images from different places together... and then operate on them in common ways. Very very cool....
It brings up more technical problems though, like what if the database isn't current or perfectly matched to the filesystem... you'll have trouble forming groups from the filesystem as albums currently do. You need that database synchronicity that ZP's not designed for yet (and for good reason-- it's currently based on the filesystem with the database as a metadata storage facility only, not as a data or query source)... but that could be improved with incremental folder scans and garbage collecting (eg: not all at once, just in parts, like GC a folder when an album is loaded, or pre-load traverse all folders when the gallery is loaded, or garbage collect every 30 minutes, etc. There are ways we could make it work...)
Okay, just thinking out loud. Tell me what you think! Thanks.
Alex Wilson
I rather like the idea of Album, Tagset, SearchResult?, etc being subclasses of Group. Group is just a collection of Items, and the subclass can determine how to populate it.
I say Item, since if Image is a subclass of Item, then so could Video, DownloadableFile?, or other individual item classes that people want -- I, for example, know I want to have an Image-type class that behaves differently on the tag context it is being viewed in. There would be a lot of options for extensibility, perhaps there could be even HTML items, etc.
Now, what if Group is a subclass of Item (or at least there is a GroupItem? that is a subclass of Item that represents a Group)? Now your Group can include both images and groups -- so you can have subalbums, search results that can return folders or things like saved searches, etc. Even the gallery index can be subclass of Group (with the default view being root-level albums).
If you went that route (or even if you didn't), I'd also be very tempted to pass the URL processing to those classes -- let the URL determine the object the send the next part of the URL to. My experience so far, limited as it is, is that adding new classes means dealing with the URL handling (a la rewrite_get_album_image(), etc) a lot more than is fun. If the URL matches the object structure (and not the physical structure), then that should be a whole lot easier.
Further thoughts... As for the database/filesystem duality, I think that if you want to embrace an object model something like the above, the major change will be switching (conceptually) zenphoto from a filesystem-based system with metadata stored in the DB, to an object based data store driven off the DB, some items of which have filesystem components as part of their make up.
Anywho, I'm curious to see what you plan to do going forward. I'm still trying to decide if I next want to tackle creating a new type of image class in the existing framework, or if I'd be better hacking up the existing one. The later option might be a lot easier on me, but much less useful for the community at large.
trisweb
Bingo, I like your thinking. The URLs are tied to the album/image structure as it is right now, and that'd have to go. In place would be some kind of table of mappings, with groups being able to define their own URLs.
This is good, very good. Let's call it 1.2, after I add subalbums support to the admin I'll dig right into this. Very very cool. If you want to start sooner than me, please do. You have exactly the right idea, I trust you'd implement it as well as you're conceptualizing it :-) Just make sure to keep me in the loop ;-)
Groups as items within groups is the next logical progression.. I had that in mind a while ago, just forgot to mention it here. The technical details shouldn't be too bad... just have to think through our representations and ideas clearly and make sure everything has an interface that makes sense and holds the class abstractions...
Re: Further thoughts...
I agree somewhat. Still, I believe it's very valuable to be able to stick an image in a folder and not do anything else and have it already be part of the gallery. That, in my opinion, shouldn't go away with any new database model.
But I think we could get the best of both worlds. I mean, if you're basing the gallery on the database, you still have to find the images on disk at some point (whether through an import, or an add, or some kind of discovery), so there's no difference from what zenphoto already does. In fact I see a huge advantage to keeping that duality intact.
The big change we have to make is in keeping the database fresh and current, and I think that's not terribly hard to do. The other change is to make some parts of the database not mirrored on the filesystem (Tags, which have no filesystem equivalent, or SearchResults?, which could be saved and used as a dynamic group of images, but still have no filesystem equivalent, Dynamic or Remote images that are loaded from URLs or other Zenphoto installations, which don't have a filesys equivalent (just came up with that one...)). So those would be maintained separate of the album/image/filesystem mentality, but equally well and at no loss. As long as the database is kept up-to-date of the files on the filesystem, and does a few checks when an image is loaded then we shouldn't have a problem, and we get the best of both worlds.
Okay, on to the Wiki. I'll be copying our discussion there.
