# RE Images

**URL:** <https://www.ruby-forum.com/t/re-images/95913>\
**Category:** Radiant CMS\
**Created:** [June 19, 2006, 1:24pm UTC](https://www.ruby-forum.com/t/re-images/95913 "2006-06-19T13:24:12Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![timperrett](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c5a1d2/32.png) [@timperrett](https://www.ruby-forum.com/u/timperrett)\
**Post date:** [June 19, 2006, 1:24pm UTC](https://www.ruby-forum.com/t/re-images/95913/1 "2006-06-19T13:24:12Z")

</div>

Hey Dan

I think this is a cracking idea, something that Radiant really needs is  
coherent asset management. How you have outlined it below is exactly as  
I  
would see it working also! However, im not sure of the value of the  
image  
manipulation bits and bobs ­ im guessing this will require Rmagick or  
something similar? Maybe it would be a good idea to make the  
manipulation  
stuff optional, so take it or leave it kind of thing.

I think its a great idea on the whole however! I would be really  
interested  
in making this work. Have you started coding it up yet?

Thanks

Tim P.  
lead systems developer

/\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*/

Date: Mon, 19 Jun 2006 14:34:55 +1000  
From: “Daniel S.” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
Subject: [Radiant] Images  
To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
Message-ID:  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
Content-Type: text/plain; charset=“us-ascii”

I’ve totally got to stop letting myself get distracted - but at least  
this is something that I will actually need, and I thought I might push  
ahead with this first as it’s got more immediate benefit to the core  
product than my other changes.

Adding Images (and other things, in general ‘assets’). I’m going to  
actually go ahead and implement this over the next week or so in some  
shape or form, and would like to get some feedback on the following in  
before I start coding things up (if I don’t get feedback, I’ll just go  
with whatever I think is right… I’ll indicate which way I’m currently  
leaning):

1. Storing of assets  
Should this be in the database or on the filesystem? I’m leaning towards  
the db angle, just to have everything in the one place. Caching will put  
it on the filesystem, but the db should be master I think. Conversely, I  
don’t know how stable the blob support in the databases and their  
respective rails connectors is, and there can also be resource problems  
unmarshalling large assets from the database (does activerecord let you  
stream a blob out of the db?), so it might be very resource-hungry to  
pull out a large pdf for example. Anybody have much rails-based  
experience with blobs?  
[http://www.voxclandestina.com/computing/ruby/rails/2005-05-24/improving-](http://www.voxclandestina.com/computing/ruby/rails/2005-05-24/improving-)  
activerecord-part-1/ suggests this might be a bad idea, but I don’t  
think we need to worry too much because a) the userbase for the admin  
pages is low b) it’s rare to put something over a meg or 2 on a website  
(isn’t it?), c) rails caching should handle putting the asset onto disk  
for fast serving. I’d intend of having the asset data in a separate  
table from the metadata, so looking up the list of assets shouldn’t be  
affected by having blobs about.

2. Administration of assets  
Should an asset just be another page in the sitemap or should it be  
something that you manage actually on the page itself? This is probably  
the big question. It makes a lot of sense to be able to add assets to a  
page while you’re entering the content - “blah blah blah history of  
france blah, picture of france, blah” - you’d probably want to be able  
to add the image at that point rather than finishing up the article and  
then having to add images on the sitemap screen. Conversely, being able  
to manage assets through the sitemap screen gives you a nice unified way  
of looking at the site, and using the single-table-inheritance stuff  
that I’m planning should allow an asset to basically be ‘just another  
page’. in the site - which really it is. I’m probably going to go down  
the second path, but might add some stuff to the page editing screen to  
be able to manage assets from there too (using an iframe-based popup so  
as not to interrupt editing - have a look at what livejournal does).

3. Image manipulation - I’m thinking of putting together a controller  
that behaves somewhat similar to amazon’s image manipulation code (see  
[Abusing Amazon images](http://aaugh.com/imageabuse.html)) - this would make things very  
flexible, allowing you to write things like "\<r:image path=“bob\_geldof”  
size=“600x”\> and have that translated into a url that the  
‘AssetController’ class could then interpret to create a string of  
manipulations to the image/asset (though I don’t really know what  
manipulations would be used for a non-image asset). Initially this will  
just consist of resizing, rotation and possibly drop-shadows, but  
hopefully I can figure out a way to make it plugin-based so you can do  
all the other amazon-like magic (overlay %off images, or whatever other  
manipulations you can think of).  
The only downside to this is that you’d open yourself up to people  
abusing your image manipulation libraries and eating up all your  
resources, but I might introduce some check-summing code to make sure  
that you can only do the manipulation if you have access to a shared  
secret (ie, so the \<r:image\> tag would know the secret and add the  
checksum param but if you tried changing settings as an end-user you’d  
end up with an invalid manipulation string).

* * *

This e-mail has been scanned for all viruses by Star. The  
service is powered by MessageLabs. For more information on a proactive  
anti-virus service working around the clock, around the globe, visit:  
[http://www.star.net.uk](http://www.star.net.uk)

---

<div class="post-metadata">

**Author:** ![timperrett](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c5a1d2/32.png) [@timperrett](https://www.ruby-forum.com/u/timperrett)\
**Post date:** [June 19, 2006, 2:36pm UTC](https://www.ruby-forum.com/t/re-images/95913/2 "2006-06-19T14:36:57Z")

</div>

I agree, this is a great idea. My input is that you keep this as a  
separate piece and like Tim was saying keep the image manipulation to  
a minimum or separate also. Try to keep the asset management simple  
and clean. I do think however since this would entail images as well  
as pdf and other documents you would want at least a 10MB limit,  
1-2megs is small. I would vote to keep the assets out of the database  
for speed issues.

Chris-

On Jun 19, 2006, at 7:23 AM, Tim P. wrote:

> manipulation
> 
> with whatever I think is right… I’ll indicate which way I’m  
> don’t know how stable the blob support in the databases and their  
> think we need to worry too much because a) the userbase for the admin  
> something that you manage actually on the page itself? This is  
> unified way  
> that behaves somewhat similar to amazon’s image manipulation code (see  
> all the other amazon-like magic (overlay %off images, or whatever
> 
> Radiant mailing list  
> removed\_email\_address@domain.invalid  
> [http://lists.radiantcms.org/mailman/listinfo/radiant](http://lists.radiantcms.org/mailman/listinfo/radiant)

Chris Corriveau: CTO of Genevate - P.O. Box 1829, North Falmouth,  
MA 02556  
contact | removed\_email\_address@domain.invalid - 508.564.5676 ext. 202 | toll free -  
866.GENEVATE  
Visit: [CapePropertySearch.com](http://CapePropertySearch.com) has graphs and trends on over 6,500+  
Cape Cod properties.

---

<div class="post-metadata">

**Author:** ![timperrett](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c5a1d2/32.png) [@timperrett](https://www.ruby-forum.com/u/timperrett)\
**Post date:** [June 19, 2006, 3:31pm UTC](https://www.ruby-forum.com/t/re-images/95913/3 "2006-06-19T15:31:48Z")

</div>

When putting files on a filesystem, please keep in mind that many  
filesystems become incredibly slow when you’re using more then a couple  
of hundred files in a directory.

```
 Erik.
```

---

<div class="post-metadata">

**Author:** ![timperrett](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c5a1d2/32.png) [@timperrett](https://www.ruby-forum.com/u/timperrett)\
**Post date:** [June 19, 2006, 3:40pm UTC](https://www.ruby-forum.com/t/re-images/95913/4 "2006-06-19T15:40:59Z")

</div>

On 6/19/06, Erik van Oosten [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> When putting files on a filesystem, please keep in mind that many  
> filesystems become incredibly slow when you’re using more then a couple  
> of hundred files in a directory.

One way to handle this (that I’ve used in the past) is to expand the  
id of the asset to a reasonably large number of digits (zero padded)  
and split it into several subdirectories.

Example w/ 10 digits: Asset with id of ‘1134’ is placed in directory  
assets/00/00/00/11 as ‘34’

Not sure if this is _the_ solution to the problem, but it’s what I use.

Cheers,  
Bruce