Consider saving crops as media items that reference other media items

[boutell]

Before we make everybody change their code to deal with the new cropping data and remember more than just an ID for each media item in every piece of code that uses one, we should seriously consider this proposal:

1. Make a new media item in the database (but NOT a copy of the original image) when a crop is saved as part of a selection
2. Give it a unique slug like originalslug_CROP_50_50_200_200 (for total compatibility with existing routes), or maybe originalsug_[50_50_200_200] (might need tiny route changes)
3. Parse the cropping parameters out of the slug (trivially, with sscanf) in the executeImage method of aMediaBackend rather than introducing a new route for cropping.

If we do this, cropping becomes 100% backwards compatible with existing sites etc., including things like user profile pictures in client projects. No API changes, etc.

The media repository would need to know not to show crops in the index, I think this is a simple change in one spot. We would also need to locate crops and delete them when the parent media items die, which could be done with a LIKE query on the slug, or we could do a schema change to include a "parent_id" to accelerate it. parent_id would be a lot less opaque.

It would be easy to offer reuse of crops with this approach (no big deal if we choose not to, but it becomes easier if we want to).

Me and Jake and Spike and Geoff think this is totally the answer, but then again we've had a beer (hey it's 7:21pm and we're still in the office on Memorial Day). Opinions welcome.

[agilbert]

Sounds good to me.

[jn78]

Another solution, is to save crop info in linking table between media _item and slot.

Pros:
- Big one: you may show the same picture in two ways: cropped and original, example: interesting part croped and zoomed for listing of posts and full scale image in full post page.
- you dont change originals, so its also 100% compatibile with existing repository.
- easier deleting, cause its reference table, so its straightforward.

Cons:
- some changes in model to include referenced info.

What do you think about that?

[boutell]

jn78, you have a point about access to the original uncropped image sometimes being desirable. But code that cares about that could still accomplish it if we add a getOriginalItem() method to the aMediaItem class. And code that doesn't care about it wouldn't have to change, which is a big win for us because quite a bit of code already uses the media selector and could benefit from cropping with no modifications.

So I think we'll just add a way to access the original media item if the issue comes up in practice.

[boutell]

Actually we'd probably just add ways to easily get an uncropped embed code rather than needlessly hitting the database.

[tboutell]

Merged in [1917]