A statement in general about extensions: If your extension has any
dependencies, it's best to include them in the lib/ directory of the
extension. That way you can avoid any 'dependency hell'. The exception, of
course, is gems and other libraries like RMagick that are potentially
system-specific (i.e. binary) or require installation. The thing I liked
about acts_as_attachment is that it still works even if you don't have
RMagick.
Sean
On 1/25/07, Kevin Ansfield <[EMAIL PROTECTED]> wrote:
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
_______________________________________________
Radiant mailing list
Post: [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
