jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Abey Mullassery" <a...@mullassery.com>
Subject RE: Image taglib
Date Thu, 06 Dec 2001 12:15:50 GMT

Yes, its right, I am not suggesting a single monolithic class for all image
manipulations but a class for each manipulation which can be added even at

The problems of adding new image actions are there even if we want JSP Tag
handlers to do the image creation. When a new ImageAction Tag is created,
changes will have to be made to accommodate it. Otherwise a slightly more
complicated generic way for image exchange has to be developed between all
tag handlers, in this case too.

The advantages of the Servlet handling the image creation instead of the Tag
Handler itself are that
	The image urls are valid always.
	Images are created only if required/ requested
	Text(html) is returned ASAP by the server.
	An additional call to the Servlet from the JSP Tag Handler is saved.
	Easy to identify the same request based on the same url.

The advantages of following the ImageActionManager/Factory class design is
	New Action classes can be added even at runtime.
	No change in the servlet or Manager/Factory class for each addition of
	Easy to have multiple manipulations on the same image in the specified

The ImageManager in my example is essentially a Factory class too.
Lookup tables are not required if a naming convention is followed. Even in
the case of a properties file, adding a new Action  does not affect any
other existing classes, i.e., a new image action can be added to the library
without changing a single line of code in any of the functioning classes
including the servlet and Manager/Factory class. Since the ImageAction class
is instantiated using reflection, the class can be added even at runtime
anytime before it is called.

The main players are:
		Checks for the image in the Cache and creates new image if not found in
ImageCache, using the ImageActionManager

	ImageAction Manager/Factory
		Dynamically instantiate an Action class (if it is not already
instantiated) and perform manipulations on the image.

		Used to cache dynamic images and garbage collect them

	ImageActionClass -- implements interface ImageAction
		Each class which does one image manipulation. Some might use a combination
of other existing ImageActions.

	IDGenerator -- (used by JSP and Servlet)
		Generates ID based on expiry time and can validate it later.

Basic working is, when an ImageServlet  url such as

"  -- (there might be better ways of encoding the url, any ideas?)

	1. ImageServlet uses the IDGenerator to validate the id
	2. Checks for an image for a similar url in the ImageCache. (go to #4 if
	3. ImageServlet makes a hashtable of parameters and a list of Actions asked
for and iterates through it
		3.1 Calls ImageActionManager's performAction(action[0], imageRef,
			3.1.1 The ImageActionManager instantiates the "LoadAction" and calls
doAction(imageRef, parameters) which returns an image
		3.2 Calls ImageActionManager's performAction(action[1], imageRef,
			3.2.1 The ImageActionManager instantiates the "ContrastAction" and calls
doAction(imageRef, parameters) which returns an image
		3.3 Calls ImageActionManager's performAction(action[2], imageRef,
			3.3.1 The ImageActionManager instantiates the "BrightnessAction" and
calls doAction(imageRef, parameters) which returns an image
	4. ImageServlet streams back the gif/jpeg/png image.

Everyone's comments please..

Abey M. Mullassery
e: abey@mullassery.com
w: http://www.Mullassery.com
Live; Don't just exist.

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