Images

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-
    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
    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).

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.
[email protected]
www.kyleheon.com

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

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/000430.html

And of course the tentative Road map:

http://lists.radiantcms.org/pipermail/radiant/2006-May/000165.html


John L.
http://wiseheartdesign.com

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.

On 6/19/06, John W. Long [email protected] 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?

Maurizio B. wrote:

On 6/19/06, John W. Long [email protected] 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

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. :slight_smile:

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

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”. :wink:

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
http://www.subscribermail.com/

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

Ryan P. wrote:

Maybe. This isn’t a democracy. It’s a dictatorship. Albeit a benevolent
dictatorship. :wink:

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

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. :slight_smile:


John L.
http://wiseheartdesign.com

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. :wink:

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
http://www.subscribermail.com/

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.

| Privacy Policy | Terms of Service | Remote Ruby Jobs