[Catalyst] (Beginner) Plugins

[Yuval Kogman]

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 <nothingmuch at woobling.org>
http://nothingmuch.woobling.org  0xEBD27418

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://jules.scsys.co.uk/pipermail/catalyst/attachments/20061024/61d5626e/attachment.pgp