Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Integrate an asset management solution #92

Closed
jlong opened this Issue Feb 18, 2010 · 8 comments

Comments

Projects
None yet
4 participants
Owner

jlong commented Feb 18, 2010

I'd like to see something that combines the approach of page attachments and paperclipped. Here are my goals:

  • Has graceful support situations where you don't have ImageMagick or something similar for thumbnails
  • Allows you to attach files to a page and view all of your files in a browser of some kind
  • Allows you to easily insert an image into the content of your page
Member

gerrit commented Apr 22, 2010

What's against just using paperclipped? it seems to be by far the most popular solution out there. imho, it would only need a few improvement, really:

  • spec coverage(!)
  • different UI showing the images that are already attached (could be as simple as moving the “attached assets” tab out of the “assets bucket” and below the page editing form)
  • cleaned up asset browser UI (searching/filtering is confusing at the moment)
Owner

saturnflyer commented Apr 26, 2010

I'm not sold on paperclipped as it is. I don't like that the plural "assets" is used for a singular object as well as multiples, and the documentation for the tag suggests using a "title" attribute yet when dragging/dropping with the UI it uses an "id" attribute. This is confusing. So that, the list you provided, and others are reasons against just using paperclipped.

Member

gerrit commented Aug 9, 2010

but surely, these are minor points that can be corrected quicker and easier than a new asset system can be built from scratch, right?

Owner

jlong commented Aug 9, 2010

Possibly.

Owner

saturnflyer commented Aug 9, 2010

Redoing can be easier than undoing, sometimes.

The SNS extension, for example, was a great idea, but the implementation of a better solution was actually much easier than the existing code. Starting with what existed and working toward something better would have actually been more complicated. See my comments here about Sheets http://github.com/radiant/radiant-sheets-extension/blob/master/README.md

Member

gerrit commented Aug 9, 2010

Sometimes it can, sure. But whenever I feel the urge to rewrite I think of a classic Joel Spolsky Essay.

Don't get me wrong, the lack of specs and general untidiness of paperclipped makes me feel uneasy too. It definitely has lots of room for improvement. But its proven in the field and widely used. Any new solution would probably leave lots of users unable to upgrade to it, either because of incompatibilities or because migration would be too hard.

Owner

saturnflyer commented Aug 9, 2010

I agree somewhat, gerrit. Paperclipped itself has a way to migrate from the page_attachments extension and I don't recall that ever being a problem.

I'm actually working on paperclipped as I have time to fix up the UI a bit. But it's easy enough to load paperclipped, or media_maid, or page_attachments, so I don't feel rushed to pull anything into the core.

We've been very slow to add features to the core and the extension system makes this simple to overcome. Do you feel that this is a mistake for some reason?

Owner

jlong commented Aug 10, 2010

This is totally a dev decision in my mind. The new solution could be built on top of paperclipped, be something completely new, or (more likely) use code from paperclipped and other solutions. I'd like to see an easy upgrade path too, but I don't think that means choosing PaperClipped. It's a matter of building smart migrations.

spanner is working on something that looks promising. It's called dragonfly.

Whatever the solution, I'd like to see something that pulls features from both page_attachments and papperclipped.

@ghost ghost closed this Jun 1, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment