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):
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-
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.
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).
Image manipulation - I’m thinking of putting together a controller
that behaves somewhat similar to amazon’s image manipulation code (see Abusing Amazon images) - 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).
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.
My initial ideas on resource/assets management in radiant from a user
standpoint.
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.
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.
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).
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.
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:
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.
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?
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
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
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
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.
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.
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
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
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 <r:image> and/or
<r:asset> 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.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
