Hi Daniel,

I see you mention that your extension uses FlexImage, is this reflected in
your svn repository? The only reference I can see is that you have the
following in your attachment model:

 def self.flex_available
   Object.const_defined? :FlexImage
 end


Is FlexImage used within your extension at the moment? Maybe I'm just
getting confused as to how you're using it, as I can't see any benefits over
the usual acts_as_attachment/RMagick combination.

Kev


On 1/22/07, Daniel Sheppard < [EMAIL PROTECTED]> wrote:

> I had mentioned this in the Radiant Core list a little while
> ago because
> I wanted people to test it out before I distributed it more
> widely, but
> I think it's time to let it loose.  Unlike the other
> extensions I have
> released in the last few weeks, I'm not putting this one in
> the Radiant
> repository, but keeping it in my own.  It may end up there
> later, however.

I just got around to testing this out to compare it with my own asset
extension
( http://soxbox.no-ip.org/radiant/svn/extensions/part_assets/)

My extension is a little rougher around the edges than yours at the
moment, but I'm planning on spending Tuesday night fixing that up (and
removing the dependence on my other admin_parts plugin) - it's currently
much f. In the meantime, could you please give my extension a spin an
make any notes as to what you'd like to see changed to try and bring our
extensions together?

Some differences:

- I've put the creation of a new asset into a popup window. Uploading of
the asset happens when you submit the popup.
My approach has the advantage that you immediately see the thumbnail of
the image, and also the filename of the image, so that it's a much
easier thing to explain to people what to put in the <r:attachment
name="blah"> tags. My approach also keeps attachments around in the case
of a validation problem, and also ensures that the upload of the image
occurs only once. In the popup, I've also made Title an attribute of an
attachment. I'm not sure if that's a good idea or not generally, but I
wanted it for my stuff - I use the title in the title attributes of
images, and it also gives another way to get reference the image.
Regardless of whether title should be included there, using a popup
gives somewhere for more attributes to go (transformation settings?
notes?). One downside of my approach is that an asset uploaded for a
page that is never saved is still going to sit around, but that's not a
biggy.

- I've decided that the removal of assets should be another page down -
the attachment gets its own page to edit the metadata (I haven't checked
this into my svn... ok. I haven't done it yet.)

- I've put in a lot more flexibility with image transformation using
FlexImage. This provides a standard mechanism for doing resizing and
prettying up - there needs to be some sort of image transformation
library used. Implementing a transformation requires only dropping a
.flexi file into the views folder. The downside to the approach that
I've taken is that image transformation happens at request time and goes
through the radiant cache - This will hopefully not be a problem once I
get get action_cache working (see earlier posts by me), which hopefully
will get done before the end of the month (my webserver wont like me if
I go live without it).

- I store the original attachments in their own directory (not just in
public/). I might make these blobs in the db - single thing to backup,
and supports scaling to multiple webservers. The only reason I haven't
is that the rails logging will log the contents of those blobs in dev
mode, making the logfiles explode. Will probably make this optional.

- The urls for assets are referenced by users as sub-urls of the page
that they're attached to. This allows assets to be added to unpublished
pages on the site and also remain unpublished. Also the urls look nicer.
The downside is that /asset/ anywhere in the site will go through the
asset controller method, but that's not really a problem as it delegates
back to the page finding mechanism if it doesn't match an asset.


Dan.
_______________________________________________
Radiant mailing list
Post:   [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

_______________________________________________
Radiant mailing list
Post:   [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

Reply via email to