Hi there,
I’m happy to announce a new minor release of file_column. It contains
two small fixes.
-
You can now serialize objects that have a file_column again, which
is important if you want to store these objects into the flash or the
session.
-
If you want to use the RMagick integration and you’ve installed
RMagick yourself (instead of as a gem) it should work right out of the
box.
Apart from these fixes, the plugin is finally available at a public
svn repository, so that you can use the cool new plugin script, rails
features in its latest release candidate. The repository is at:
https://opensvn.csie.org/rails_file_column/plugins/file_column/
Installation is as easy as typing
./script/plugin install
https://opensvn.csie.org/rails_file_column/plugins/file_column/trunk
(you can still get an archive at
http://www.kanthak.net/opensource/file_column/)
in your project’s directory. Warning: The trunk can be unstable. You
can find stable releases in the tags directory. Is there a standard
way of telling the plugin script about which version to use? I’m a bit
confused here, because the standard layout of plugin repositories does
not seem to contain the standard tags or branches directories. Can
somebody educate me about the repository conventions for plugins? How
do you make sure as a plugin developer, that your users only use
stable versions by default?
On a different note, I need some input on the future directions of
file_column, so that it suits your needs as well as possible. I have
already discussed some of these ideas with Kyle M… Thanks a lot
for your input, Kyle!
Basically I want to keep file_column as lean and general as possible,
while providing some more features that have been requested often and
making it easy for you to implement your more exotic needs. So here
are two points, where I’d be happy about feedback:
-
Right now, I’m using the RMagick library to use the imagemagick
toolkit. Is it hard to get this working under Windows? Would you
prefer file_column calling the imagemagick commands directly? I’d like
to keep the dependency on the RMagick library as it allows for much
more beautiful code and easier handling of images.
-
The versions feature allows you to declare in the model, that
several different sizes of an image should be stored that can
subsequently be accessed from your view. Kyle and I feel that this
information doesn’t really belong into the model, so Kyle suggested
that you can specify a geometry string in the view’s
url_for_file_column method. If an image does not exist in these
dimensions already, it will be created transparently and stored so
that it can be used again in the next request.
What do you think about this feature? Does it make sense? Should it
replace the declaration of versions in the model completely or should
it be an additional feature?
Thanks for all the encouranging feedback I have received so far!
Sebastian
The plus side is that if you add a new size, you don’t have to re-input
the
images to get the new sizes.
I think that this is a great idea as long as the images are generated
only
if they don’t already exist. Having to call ImageMagick for every
request
would kill performance for us on the 5MM/month page view site we are
developing.
The thing I like about having it in the model is that I don’t have to
type
that geometry string all over… DRY and all that good stuff.
Hi Sebastian,
thanks this new release!
just fyi, i think there maybe a typo in the install url? I only
managed to install with ‘http’ instead of ‘https’
about the last feature you asked about, I used kyle’s original
imagemagick helpers for a while and found them very useful for stages
in development when thumbnail sizes may vary. my (humble) 2 cents
would be that it makes sense and keeping versions defined only in the
view would keep things DRY…
2005/11/14, Sebastian K. [email protected]:
On 11/15/05, Hunter H. [email protected] wrote:
The plus side is that if you add a new size, you don’t have to re-input the
images to get the new sizes.
good point.
I think that this is a great idea as long as the images are generated only
if they don’t already exist. Having to call ImageMagick for every request
would kill performance for us on the 5MM/month page view site we are
developing.
yes, the resized images would be stored in the file_column directory
by default so that they aren’t regenerated if the same size is
requested again.
The thing I like about having it in the model is that I don’t have to type
that geometry string all over… DRY and all that good stuff.
you could put the geometry string in a helper to keep DRY. Another
option would be to keep the definition in the model as a way to define
short-names for geometry strings.
Sebastian
On 11/15/05, Oliver B. [email protected] wrote:
just fyi, i think there maybe a typo in the install url? I only
managed to install with ‘http’ instead of ‘https’
oh, good catch. You need a svn account for the https URL to work… So
here is the correct URL again:
http://opensvn.csie.org/rails_file_column/plugins/file_column/
Installation is as easy as typing
./script/plugin install
http://opensvn.csie.org/rails_file_column/plugins/file_column/trunk
Sebastian
Personally, I like this last option. Sounds concise.
Sebastian K. <skanthak@…> writes:
- Right now, I’m using the RMagick library to use the imagemagick
toolkit. Is it hard to get this working under Windows? Would you
prefer file_column calling the imagemagick commands directly? I’d like
to keep the dependency on the RMagick library as it allows for much
more beautiful code and easier handling of images.
I found it a snap to get working under windows as-is.
Dave
On 11/15/05, Sebastian K. [email protected] wrote:
How do you make sure as a plugin developer, that your users only use
stable versions by default?
From what I can tell, at the moment the plugin script’s install
mechanism won’t recognise tags or branches at all, if if I’m right
(please someone tell me I’m not?) if you have your repository
organised something like:
svn://your_svn_url/your_plugin
|-trunk
|-branches
|-tags
|-0.1.0
|-0.1.1
… then script/plugin install will pull the whole repository down :S
I believe (from a comment that I posted on the wiki Plugins page) that
some work is being done to support tagged releases, but I’m not sure
when or what we’ll see. Fingers crossed…
Hi there,
First of all thank you very much for this excellent plugin.
Answering your questions… yes, I run RMagick in Windows and it is a
@#^#@&# pain. Right now it just doesn’t work, I’m still trying to
figure out which upgrade broke it. But it is not your fault. 
Now the request… 
One feature I could really use is something
like a before_filter… I made a “poor man’s Flickr” for my wedding
pictures (not using file_column) and one of the things I do besides
the resizing is a crop to make the thumbnail square, a la Flickr.
Setting the JPG compression would be another use for this
pre-processing. More fancy ImageMagick processing could also be easily
integrated…
Anyway… just throwing some ideas around. 
Yeah, I too would definetly like to have a way to crop the photo being
uploaded in an effort to consistently make square thumbnails.
I’d be interested to see how others are doing this currently while using
FileColumn.
Many thanks for FileColumn, it’s a huge time saver.
Kyle H.
[email protected]
my guess is that you’d pass a :crop argument just like you can with
:geometry?
I’m assuming (haven’t tested it yet) that all imagemagick commands are
accessible this way:
2005/11/15, Kyle H. [email protected]:
actually, I think I may have guessed wrong. I just had a look at
magick_file_column.rb, from what I could make out of the code (my
knowledgeg of ruby is limited), it seems only resizing is working
right now…
2005/11/16, Oliver B. [email protected]:
If anyone’s curious, they can check out my branch (
http://opensvn.csie.org/rails_file_column/plugins/file_column/branches/kyle/
), which includes the following changes:
Changes:
- Removed the “versions” implementation.
- Removed RMagick dependency
- Complete rewrite of Imagemagick functionality. It uses
IO.popen(“mogrify …”).
- Added url_for_file_column “model”, “field”, :magick =>
command_options. You can pass command options as a string or
a hash:(“-resize 100x100” or :resize => “100x100”)
- Added validates_extension_of(*attr_names). This takes either a
string or an array of extensions. It validates that the file has one
of the extensions listed. If it doesn’t it tries to convert the file
to the first extension in the list using imagemagick. If that fails,
then it adds a validation error to the model.
Todo:
- Merge the 0.3.1 updates.
- Add more tests
- Add better support for multi-environment use. In addition to the
production vs development, multilingual concerns have come up. I’m
using the multilingual plugin, and I might need to grab a different
version of a file for each locale. How to make this easy without
increasing overall complexity?
Kyle,
Interesting work.
Does your branch save the results of the transformations so they don’t
need
to be run each time they are displayed (i.e. Changing the size only
creates
a new file the first time and subsequent requests pull up that file)?
Hunter
It would be great if you could set prefered image formats along with
resizes - smaller files usually look better in png or gif but with
larger files jpeg has a better quality/size ratio.
I reckon Rmagick has no ‘convert’ method per se (it converts formats
on-the-fly when a file is saved with a different extension) that’s the
main reason I’m going to tamper with the code for file_column a bit…
spe.
If you use my branch, assuming png support is compiled into
imagemagick, you can:
url_for_file_column “model”, “field”, :magick => {:format =>“png”,
:resize => “10x10”}
Alternately:
url_for_file_column “model”, “field”, :magick => “-format png -resize
10x10”
0.3.0 only supported the :geometry option, and that should be true of
0.3.1. Try my branch for generic imagemagick capabilities. You can
pass any of the command line options, but remember that my branch is
experimental (although I use it in my production sites), and that
imagemagick transformations are handled in the view
(url_for_file_column).
Sebastian K. wrote:
Hi there,
I’m happy to announce a new minor release of file_column. It contains
two small fixes.
Please correct me if I’m wrong, but a little playing with file_column
tells me that the file name is being stored in the file_column and it
will be retrieved for display from the saved place from the /public
folder. Is there a way I can save the image itself in the file column
(that was my original assumption). Which approach is better? Saving
images/files in the database or a regular file system?
TIA,
Vamsee.
cool, i’ll give it a try!
spe.
hi kyle,
I installed your branch and am getting the following error when booting
webrick:
(from locomotive) dependencies.rb:200:in `const_missing’:
uninitialized constant BaseUploadedFile (NameError)
from
./script/…/config/…/vendor/plugins/kyle/lib/magick_file_column.rb:2
though I can see the BaseUploadedFile class in file_column.rb.
thanks
Oliver
2005/11/16, Kyle M. [email protected]: