zdravko.balorda at siix
May 29, 2011, 11:03 PM
Post #4 of 6
(1399 views)
Permalink
|
David E. Wheeler wrote:
> On May 27, 2011, at 12:45 AM, Zdravko Balorda wrote:
>
>> Excellent! This solves it. It feels like there exists a generic thumbnail handling
>> approach. Something like:
>> $burner->get_thumbnail($img, {'width' => xx, 'height' => yy, 'crop' => 0/1, ... } )
>> which (re)creates (check file mtime) a thumbnail media document of type Thumbnail
>> (hidden from users), makes it related to $img, considers other configuration options,
>> etc. etc. and returns thumbnail media document, that being related, will be published
>> along with the original image. A user don't need to care about anything. There can
>> be as many thumbnail images as are needed. Even too many, actually ... ?!
>
> You mean find_or_create_alternate()?
>
> http://bricolagecms.org/docs/current/api/Bric::Biz::Asset::Business::Media::Image#Public-Instance-Methods
>
Yes, in part. The rest is a maintenance and a CMS issue.
There is another, even better approach, I just don't know if it works.
A thumbnail could (should) be related to a burning story, a story that displays it,
instead to the original media document. This way there would be only as many thumbnails
as needed, not like here, where every media has a bunch of thumbnails regardless. But this
may require a story to check out itself, create images, and then save and check in again while
being published... or just save if being previewed while checked out...
Regards, Zdravko
|
