jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Bayern <bay...@essentially.net>
Subject RE: Image taglib
Date Thu, 06 Dec 2001 16:57:28 GMT
Okay - it looks like we're converging on similar designs.  There's still
one important difference, which is highlighted by these two passages of 
your message:

> The ImageManager in my example is essentially a Factory class too.
> Basic working is, when an ImageServlet  url such as

My approach is similar, except that all image paramaters are encapsulated
*within* the factory instead of as outside data, exposed to the user.

I think the following are disadvantages of your model:

- Images must be created by String/String name/value parameters.  This
  is somewhat restrictive in the general case.
- The parameters must be sent over the URL to the user.
   - This exposes too much information to the user, allowing her
     potentially to use us as an engine to create 'inappropriate' images
     (or at least ones we never intended to produce).
   - The URL might exceed 256 characters, in which case proxies (etc.)
     may choke on it.

You mention that under your model, "there might be better ways of encoding
the URL."  I'm suggesting precisely that:  we abstract parameters behind
an ImageFactory and expose simply a unique identifier in the URL.  This
ImageFactory can be constructed with a HashMap of parameters (in your
case), or anything else (in the general case):  e.g., an InputStream, a
URLConnection, etc.

I'm thinking not in terms of a single hierarchy of tags but a general   
model into which new sorts of image generation can be inserted.  I would
initially envision the following:

                      ImageTagSupport (registers ImageFactory w/servlet) 
                        /    |     \
                       /     |      \
                      /      |       \
                     /       |        \
                    /        |         \
      ParametricImageTag  SVGImageTag  [Miscellaneous]

The tags that you (Abey) are thinking of can be covered by
ParametricImageTag.  Bob's proposed SVG-based generation could be
separate, and miscellaneous tags I'm envisioning (e.g., "convert TIF to
JPEG from InputStream") could still be accommodated.

As a side advantage, this model avoids any need for naming conventions, 
lookup tables, and so on.  It adapts to anything that wants to produce a
BufferedImage -- or potentially other sorts of images.
> Easy to have multiple manipulations on the same image in the specified >
> order.
So, as an example, this can be handled by a particular kind of
ImageFactory (along the lines of the one you're proposing -- with a
HashMap of String/String parameters).  But why limit the entire framework
to this specific case?

As another example:  not every image will be tied to a particular
"filename."  Including this as a core feature of the framework just seems


To unsubscribe, e-mail:   <mailto:taglibs-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:taglibs-dev-help@jakarta.apache.org>

View raw message