On Tue, Oct 24, 2006 at 10:06:05 -0400, Alejandro Imass wrote: > Thanks for your ideas... > > The issue is that the client specified that images be kept proportional no > matter the size of the browser, so if I resize the browser I have to > regenerate the image so it keeps in proportion with the new window size. One > would think this could be easily done just by changing the size with > JavaScript but: > > a) Browser resizing distorts the images > b) The anchor for our images is the lower right hand corner and we have to > crop the top-left. This is because images can be of many different > proportions and the final layout has a fixed proportion. > c) The client wants the images to degrade to black on the right edge. > > Obviously this requires server-side processing. I agree with you on > dynamically generating the images. In fact, I was thinking of using AJAX > with the Dojo plugin.
Ouch, what an insane client...
I hope you're charging them $$$ ;-)
Anyway, what I'd do is use js to set the bg image to
$uri_base/images/$image?width=$x&height=$y
and then generate this image with a dynamic action. It should be
simpler.
Use ImageMagic/Imager/GD or whatever to dump out a scalar, and then
put that in $c->response->body, and set the content type
appropriately, in something like
sub images : Local {
my ( $self, $c, $image ) = @_;
my ( $width, $height ) = map { $c->request->param($_) }
qw/width height/;
my $cache = $c->cache("images");
my $key = join(":", $width, $height, $image );
my $scaled = $cache->get($key);
unless ( defined $scaled ) {
my $img_object = $c->model("Images")->get_image( $image
);
$scaled = $img_object->scale_and_fade(
width => $c->request->param("width"),
height => $c->request->param("height"),
);
$cache->set( $key => $scaled );
}
$c->response->body( $scaled->as_string );
$c->response->content_type( $scaled->mime_type );
# make sure to set the caching control headers, like
# expires, cache-control, last-modified, etc
}
and make sure that $scaled can behave nicely with Storable.
The reason I suggest doing this and not adjacent files is that the
key space cardinality ( image * width * height ) is very big. If you
only need width that's better, i guess, but there's still a
potential to easily have several hundred versions of a single image.
Using one of the Cache modules on the CPAN you can constrain the
cache to say 200MB and still get decent performance.
I hope this helps
> Now, regarding my original question on the use of plugins or not. Can you
> tell me, like for dummies, what are the advantages or disadvantages of using
> a Catalyst plugin or using the CPAN modules with a simple use. For example,
> if I decide to dynamically generate the images would I need or have any
> advantages or problems to make a plugin for Image::Magick?
The only reason to use a plugin over a regular module is if the
plugin can provided potential for better integration, by knowing
more about the app then a generic module should.
There are two more categories of plugins - ones that act on the web
specific data structures (e.g. C::P::Browser, C::P::Session), and
ones that provide services that have a potential for added value in
a webapp context. For example, C::P::Cache has no merit on it's own
like that, but in a more heavyweight setup there is benefit in the
controller just using caching services, and the configuration
providing all the know-how for choosing the right cache, etc.
It doesn't sound like any of these scenarios coincide with yours.
--
Yuval Kogman <[EMAIL PROTECTED]>
http://nothingmuch.woobling.org 0xEBD27418
pgpXv4QPOJOb7.pgp
Description: PGP signature
_______________________________________________ List: [email protected] Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
