# Images **URL:** \ **Category:** Radiant CMS\ **Created:** [June 19, 2006, 6:39am UTC](https://www.ruby-forum.com/t/images/95905 "2006-06-19T06:39:40Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [June 19, 2006, 6:39am UTC](https://www.ruby-forum.com/t/images/95905/1 "2006-06-19T06:39:40Z")
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 "\ 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 \ 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). ---
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [June 19, 2006, 1:11pm UTC](https://www.ruby-forum.com/t/images/95905/2 "2006-06-19T13:11:56Z")
1.) > From my (mostly Windows based) experiences, storing blobs in a database is > generally frowned on. It’s far easier to retrieve a file from disk then > from > the database. While I agree that having everything in one place is nice, > I’m > not sure that benefit outweights the performance concern. Additionally, I see images much larger then 1-2mb being stored as assets. Think for instance about company site where datasheets, whitepapers and product downloads might need to exist on the site. We have clients that have product downloads in the 100mb+ range. While I have no proof, stuffing that into a database and retrieving it won’t be fast. 2.) I personally think that assets should be managed externally but could be visible as assets of a page in the sitemap. For instance, if you are adding a page to the site and need to add an image, give the user the ability to do so from within the page window (a link/popup). Have this add the asset and add a reference to it on the page but when it comes time to manage this, it should be extracted out to a central area. Users should be able to update page assets from within this same workflow. Kyle H. removed\_email\_address@domain.invalid [www.kyleheon.com](http://www.kyleheon.com) ---
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [June 19, 2006, 2:03pm UTC](https://www.ruby-forum.com/t/images/95905/3 "2006-06-19T14:03:23Z")
My initial ideas on resource/assets management in radiant from a user standpoint. 1. We need to have a way to upload resources (digital assets) to a radiant powered web site (pdf files, images, binary files, etc.). I don’t think there is a general need to process the resource/image files on the server. 2. We also need to have a way to manage such resources (delete, tag management–add tag, edit, and remove tags attached to a resource or to multiple resources). This “resource management place” should be accessible from the admin menu and there must be an access control policy to this page. Also there should be a quota mechanism to control how much bytes a user could upload. 3. I don’t see, at the time being, the need to attach a resource to a page. This could be done by simply linking that resource to a page body or part. Maybe a radius tag could be created to simplify the access to the said resource (all resources should be acessible from any part of the system). 4. About placement of resources inside a database seems convenient from an administrative standpoint (only one thing to backup), but we must be certain also sqlite is supported and capable to manage objects in the range of tens or hundreds megabytes. –Maurizio ---
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [June 19, 2006, 4:19pm UTC](https://www.ruby-forum.com/t/images/95905/4 "2006-06-19T16:19:07Z")
Daniel S. wrote: > leaning): > Dan, in general I plan to implement assets as “attachments” to pages. > They will be stored in the database for portability, but permanently > cached on disk as well. Xavier has already done some work on this. And > Matt McCray was working with him on it. I wasn’t planning on implementing attachments for another couple of versions. Pluggins and Blogging are ahead on the Roadmap, but if a couple of you want to preempt me with your own code, feel free. I’d encourage you to take a look at these threads: [http://lists.radiantcms.org/pipermail/radiant/2006-May/000164.html](http://lists.radiantcms.org/pipermail/radiant/2006-May/000164.html) [http://lists.radiantcms.org/pipermail/radiant/2006-May/000430.html](http://lists.radiantcms.org/pipermail/radiant/2006-May/000430.html) And of course the tentative Road map: [http://lists.radiantcms.org/pipermail/radiant/2006-May/000165.html](http://lists.radiantcms.org/pipermail/radiant/2006-May/000165.html) – John L. [http://wiseheartdesign.com](http://wiseheartdesign.com) ---
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [June 19, 2006, 5:00pm UTC](https://www.ruby-forum.com/t/images/95905/5 "2006-06-19T17:00:06Z")
Absolutely. Additionally, when “linking” to an asset, you shouldn’t directly link to it’s relative location but rather reference it’s id. Then during publishing, resolve the assets and insert the proper link. This makes it easier to move things around as well as moving from development to staging to production. I agree that having a way to managed assets that exist on a page is helpful, I don’t agree that they should be “owned” by a page. There are many cases where you’ll need to reference assets in multiple areas. ---
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [June 19, 2006, 4:53pm UTC](https://www.ruby-forum.com/t/images/95905/6 "2006-06-19T16:53:43Z")
On 6/19/06, John W. Long [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Dan, in general I plan to implement assets as “attachments” to pages. Couldn’t assets be also logically independent from a given page? I mean, assuming you have a page where you describe a product then it may make sense to have an asset (let’s say a pdf file describing the product) associated with that page, but in another scenario you may have more than one page using the same resources (for example a logo or a photo of a team), and in another scenario, or you may have another assets which is “associated” with a page at a given time, but after some time you decide to move it to another page. At this point you need to keep track of all this movements of assets among pages, which will increase code complexity. Shouldn’t it be better to accumulate all assets in one “bucket” so that the reference (link) to then never changes when you move it, and eventually be able to tag them for easier management when in the asset administrative page? ---
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [June 19, 2006, 5:03pm UTC](https://www.ruby-forum.com/t/images/95905/7 "2006-06-19T17:03:28Z")
Maurizio B. wrote: > On 6/19/06, John W. Long [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > Dan, in general I plan to implement assets as “attachments” to pages. > > Couldn’t assets be also logically independent from a given page? There is some merit to this idea. I’m also considering the idea of adding a “styles” tab. Once plugins are fully operational it will be much easier to support multiple methods of doing this sort of thing. – John L. [http://wiseheartdesign.com](http://wiseheartdesign.com) ---
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [June 19, 2006, 5:19pm UTC](https://www.ruby-forum.com/t/images/95905/8 "2006-06-19T17:19:08Z")
Kyle H. wrote: > Absolutely. Additionally, when “linking” to an asset, you shouldn’t > directly > link to it’s relative location but rather reference it’s id. Then during > publishing, resolve the assets and insert the proper link. It sounds good in theory. 🙂 > This makes it easier to move things around as well as moving from > development to staging to production. > > I agree that having a way to managed assets that exist on a page is > helpful, > I don’t agree that they should be “owned” by a page. > > There are many cases where you’ll need to reference assets in multiple > areas. Everyone’s certainly entitled to their own opinion. I’ve managed assets like this on my own Web sites for some time now and it seems to work just fine. For Radiant you could always attach images to an “images” page if you felt the need to keep certain images in a global location. Admittedly this feels a little like a hack, but it keeps things consistent. Again, plugins should allow room for multiple perspective.s – John L. [http://wiseheartdesign.com](http://wiseheartdesign.com) ---
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [June 19, 2006, 5:19pm UTC](https://www.ruby-forum.com/t/images/95905/9 "2006-06-19T17:19:08Z")
On Jun 19, 2006, at 10:01 AM, John W. Long wrote: > Once plugins are fully operational it will be much easier to support > multiple methods of doing this sort of thing. Yes indeed! Which sounds like a powerful argument for getting that flexibility in before throwing in a feature that chooses the asset strategy for us. Don’t pull a “Rails”. 😉 That said, I wonder if there wouldn’t be a useful abstraction of assets that we could code our own strategies for? Commonalities of asset support needs: - Upload assets - Export assets with site - Reference them from layouts and pages, both in src attributes and hrefs - Manage meta-information about them - probably best to come up with a single policy that will allow uniformity and flexibility in how assets are conceptually linked to pages/layouts/sites - any other commonalities? Differences: - Storage method – DB? filesystem? plasmatron? - URLs for assets - Caching strategies - any other differences? – Ryan P. Senior Developer, SubscriberMail, LLC 3333 Warrenville Rd. Suite 530 Lisle, IL 60532 (630) 303-5072 Not Just Email…SubscriberMail > **[subscribermail.com domain name is for sale. Inquire now.](https://www.subscribermail.com/)** > > subscribermail.com is available for purchase. Get in touch to discuss the possibilities! This message (including attachments) contains proprietary information which may not be disclosed or used beyond the purposes of this message without the written consent of SubscriberMail, LLC. If you receive this message in error, notify the sender and destroy this message and all attachments immediately. Thank you. SubscriberMail is covered under US PATENT 6,769,002 ---
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [June 19, 2006, 5:31pm UTC](https://www.ruby-forum.com/t/images/95905/10 "2006-06-19T17:31:36Z")
Ryan P. wrote: > Maybe. This isn’t a democracy. It’s a dictatorship. Albeit a benevolent dictatorship. 😉 Again, hopefully plugins will be robust enough to support multiple methods of doing this. And I haven’t thrown the idea of global asset management out the window. It’s just that I want to see attachments implemented first. I’m wondering if the perceived need may go away at that point. – John L. [http://wiseheartdesign.com](http://wiseheartdesign.com) ---
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [June 19, 2006, 6:12pm UTC](https://www.ruby-forum.com/t/images/95905/11 "2006-06-19T18:12:41Z")
Ryan P. wrote: > That’s cool, Your Benevolency. Just writing down some thoughts on > what was likely to change vs. vary so those details made it into the > discussion, not to mention your own most benevolent train of thought. Which is certainly valid. 🙂 – John L. [http://wiseheartdesign.com](http://wiseheartdesign.com) ---
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [June 19, 2006, 5:59pm UTC](https://www.ruby-forum.com/t/images/95905/12 "2006-06-19T17:59:50Z")
On Jun 19, 2006, at 10:28 AM, John W. Long wrote: > > Yes indeed! Which sounds like a powerful argument for getting that > > flexibility in before throwing in a feature that chooses the asset > > strategy for us. > > Maybe. This isn’t a democracy. It’s a dictatorship. Albeit a > benevolent > dictatorship. 😉 That’s cool, Your Benevolency. Just writing down some thoughts on what was likely to change vs. vary so those details made it into the discussion, not to mention your own most benevolent train of thought. – Ryan P. Senior Developer, SubscriberMail, LLC 3333 Warrenville Rd. Suite 530 Lisle, IL 60532 (630) 303-5072 Not Just Email…SubscriberMail > **[subscribermail.com domain name is for sale. Inquire now.](https://www.subscribermail.com/)** > > subscribermail.com is available for purchase. Get in touch to discuss the possibilities! This message (including attachments) contains proprietary information which may not be disclosed or used beyond the purposes of this message without the written consent of SubscriberMail, LLC. If you receive this message in error, notify the sender and destroy this message and all attachments immediately. Thank you. SubscriberMail is covered under US PATENT 6,769,002 ---
**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\ **Post date:** [June 20, 2006, 6:27pm UTC](https://www.ruby-forum.com/t/images/95905/13 "2006-06-20T18:27:14Z")
> Dan, in general I plan to implement assets as “attachments” to pages. What I’ve done so far is introduce single-table-inheritance (which I want for my complex behaviours later anyway) so that there’ll be a structure somewhat like: Asset ±-- Page ±-- FileAsset ±-- Image The tree behaviour of pages has been moved up to asset, leaving pages with the page-specific behaviour. All that’s been needed to achieve this has been a renaming of the “pages” table to “assets” and the adding of a “type” column. Had to do a bunch of changes in the unit tests to deal with the fact that it now has a “assets” fixture instead of a “pages” one, but other than that all the tests held up. While they will be represented as just part of the asset tree in the administration interface (and also for finding with \ and/or \ tags), they will actually be served by a separate asset controller. This controller will use rails action caching to cache the assets on disk and will implement some image manipulation capabilities. This controller will probably refer to assets by id rather than path. My only real concern with doing it this way is that this extra controller is going to overlay some the site namespace (what if you’re cmsing for an asset management firm and you want to use /assets?), but we already have the same issue with /admin (which is probably a path that people will want to use for a wide variety of sites), so it’s probably nothing. (Maybe /admin should be moved to /siteadmin or something more specific? /radmin - hehe) In response to some of the other points made: - Direct manipulation of asset files on the filesystem is a BAD idea. I want to operate under the assumption that operators of radius a) know nothing about manipulating files on a filesystem, b) have no access to the underlying server. - Having assets as ‘just part of the tree’ means that you can order them around in any way you see fit. If you LIKE having a central images directory, that should be fine. - When managing images through the admin interface, you need to have thumbnails - I see that as an absolute necessity. And once you’ve got enough image manipulation to do thumbnails, you might as well go the whole hog. - I’m going to store them in the database for now - I’ll probably end up falling back to the filesystem, but I want to actually see how much pain is involved in using blobs. I’m working on the user interface changes now. I’ll hopefully have something to show for it by the end of the week.