Versions feature could be refactored into an optional app about django-filebrowser HOT 7 CLOSED

some thoughts & questions:

1. versions are not about thumbnails.
2. what´s the problem with legacy media?
3. what exactly are the benefits if we decouple the versions-app? because if you don´t need versions, it´s not in your way, right?
4. how do you deal with images on a grid-based website if you don´t use versions?

thanks,
patrick

from django-filebrowser.

Hi Patrick.

1. Of course, but generating thumbnails is one of the use cases.
2. Most of the time legacy sites will have a pre-defined convention for filenames (or no convention at all), which will then render the very notion of selecting versions in the admin based on the filenames impossible.
3. Filebrowser could be more useful for more people and easier to extend if it can provide base classes for FileObject and FileBrowserSite that don't make assumptions about how a site generates images. Then on top of that, provide a versions app that expands on this base. That achieves a cleaner code base since you are decoupling two features that are different in nature (file management and image generation).
4. I do more or less the same thing, generate different sized versions of the same image. The difference is in the implementation, since images sizes are requested by the site templates and resizing takes place using sorl-thumbnail on a task queue. It has no relation to the admin at all, it's transparent for site editors since they only have to choose the original files.

The whole issue is about refactoring it so people can use it for what the name implies (browsing files), and use more robust libraries for dealing with images since not all sites do this the same way.

from django-filebrowser.

some additional notes.

about 2: you usually don't select versions with the admin interface. actually, versions are only useful in the admin if you need to add them with a rich-text-editor.
maybe I'm not getting the point?

about 3: I do agree with the cleaner code.

about 4: how is that different to what we do with versions? editors also choose original files and versions are requested by templates.

@vam: your opinion about this issue?

I'm personally seeing some benefits in decoupling the versions app. but I don't think its important enough to do it ourselves - esp. since we're doing quite well with the current implementation of versions.

from django-filebrowser.

about 2: you usually don't select versions with the admin interface. actually, versions are only useful in the admin if you need to add them with a rich-text-editor.

Yes, that's what I meant. Also, the "versions" pane on file details and the previews are superfluous if you don't need it. On top of that, by defining an empty VERSIONS setting, the code will break in various places.

about 4: how is that different to what we do with versions? editors also choose original files and versions are requested by templates.

It's different in how the image versions are actually created. The versions logic is builtin on the FileObject accessors and in the management commands. You don't control "when" an image version is created, for instance. Also, you can't delegate image creation to another server to off-load your main web server. This is important in high-traffic sites since generating versions on the fly is not plausible, and running the management command for millions of legacy files is also impossible. So this sort of logic is very specific and varies on a per-site basis. It should have no relation with the rest of the app, which should just provide a file manager interface.

Anyway... I'm sure it's not useful to remove it for you, since you created the feature to actually use it :) But it's about making FileBrowser more reusable.

I'll come up with a patch soon for this since I want to use filebrowser in a long-term project and don't want to maintain my own incompatible fork with versions removed. Given how easy it was for me to "take out" this feature, I envision it won't be hard to refactor.

from django-filebrowser.

empty versions don't make sense. you need at least one version for the admin-thumbnail.

looking forward to see your patch.

from django-filebrowser.

Sounds like a good idea to me - see the benefits of cleanness, reusability, and performance. Also curious about the patch.

Solving the admin-thumbnail problem without duplicating code in the versions-free filebrowser and filebrowser.versions seems like a challenge to me, though.

from django-filebrowser.

There you go, first attempt: Issue #46

from django-filebrowser.