[Radiant] [ANN] Page attachments extension

[Sean Cribbs]

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 <kev at digitalblueprint.co.uk> 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 < daniels at pronto.com.au> 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:   Radiant at lists.radiantcms.org
> > Search: http://radiantcms.org/mailing-list/search/
> > Site:   http://lists.radiantcms.org/mailman/listinfo/radiant
> >
>
>
> _______________________________________________
> Radiant mailing list
> Post:   Radiant at lists.radiantcms.org
> Search: http://radiantcms.org/mailing-list/search/
> Site:   http://lists.radiantcms.org/mailman/listinfo/radiant
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.radiantcms.org/pipermail/radiant/attachments/20070125/1c56dde6/attachment.html