Zenphoto
The simpler media website CMS
ZenphotoThe simpler media website CMS
Forum search only. You might also want to search on the main site's user guide.
Your support helps pay for this server, and helps development of zenphoto. Thank you!
Visit the donations page
Comments
Also a demo available: here - there is a search box on the front page, as well as smart folders.
IPTC already has keywords. Why not use this? I would really prefer full support for IPTC over an extra tagging function.
BTW - I really do not understand this craze about tagging. If someone wants to add keywords to their pictures, I can understand it. But to have tagging in a forum like this that run on SQL is not too understandable. If the post I am making here do not contain everything that is worth searching for, why bother writing it?
Oh, well...... That is just me and my opinion. I do not mind if anyone else has a different opinion as long as they do not force it on me.
If there won't come an official way to work with tags, smartalbums and a search function, I'll have to hack something myself and I'm not good at it, so... please...
Groeten, Miriam
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?
Also, how are you storing tags? Separate database table? Referencing by Ids on each image? And is there a many-to-many mapping table, or is it a list of ids in an image field?
Also, I imagine it being quite different from the image description code. You need a text box, yes, but it also needs to have a tag list that gets updated, and preferably by AJAX of course. Some work to be done there.
Just set up SVN this morning. Did you get my email?
> Also, how are you storing tags? Separate database table? Referencing by Ids on each image? And is there a many-to-many mapping table, or is it a list of ids in an image field?
A many-to-many table mapping the images table to a tags table. The SQL ends up more complex than just storing text on the image, but it means the DB can do all sorts of snazzy selects based on tags. I already tested out some statements that do stuff like "all images including tag1 and tag2 and don't have tag3", and it worked great.
> Also, I imagine it being quite different from the image description code. You need a text box, yes, but it also needs to have a tag list that gets updated, and preferably by AJAX of course. Some work to be done there.
As I have it, the getTags() method on the image class just returns a space-separated string, and the intent is the set method will also just take a string, so for now the web-side interface can work just like description field. To that I'd eventually want to add a del.icio.us-like tag list you can just click on and have it build the string for you. The set method will then adjust the tags and mapping in the DB as needed.
Now on to some tag-based browsing!
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.
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.
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.
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.
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.
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...
How bout we start a Wiki page? Let's continue discussion there and further refine the model...
http://www.zenphoto.org/trac/wiki/ZenphotoDevModel
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.
I'm not sure if it is a good idea to also include video and sound support in Zenphoto...
-Some new features that have been asked for (tagging, searching, etc.)
-An under-the-covers redesign of the guts, which will not only make adding the new stuff easier, but make the framework extensible so other people can add their own new stuff really easily
-Maintaining the ability to just drop some images in some folders and just have everything just work.
The big discussion it may sound like that last one is going away, but I don't think that has to be the case -- we really should be able to keep that basic functionality just as simple as it is now, and have all the other bells and whistles be as transparent as you want them to be.
And Videos and Sounds are just to demonstrate the possibilities of an extensible object model; I myself wouldn't necessarily want them. They could be optional components, or plugins, or integrated to "just work" if people want to use them. I don't see the harm in that. I promise it will not be more complex than what zenphoto currently is; there will just be more under the hood, more possibilities for organization, and even simpler and easier ways to find everything you're looking for in large galleries.
For now though, the focus is on getting 1.1 out, with a redesigned Admin UI that will fully support Subalbums. After that's finished we can move on to redesigning the guts.
But for the short term, I think there are other, more important, things to implement.
http://alexwilsonphoto.com/gallery/
It's a bit of an experiment in tag-only image browsing.
There's no album view, just a view of the images that belong to a tag set, and the gallery gives you the option to adjust/change/evolve the current tag set by picking similar images to the one you are viewing. The guts of that all works on some tag stuff added to zp.
I haven't made my mind up about the "return to tag cloud" link -- up higher is much more accessible, but would add to the clutter. I kinda like it out of the way, since I'm hoping it means people will explore more instead of just going back to the tag cloud all the time. I'm gonna wait and see if I get more complaints about it before moving it anywhere
Alex,can you please share with us how you were able to accomplish this, or even if you could share the code?
thanks alot