You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Abey Mullassery <ab...@mullassery.com> on 2001/12/05 10:45:10 UTC
Generic Tags for Image Tag Actions
Right now we talked about developing tags for specific actions on images
such as make thumbnail, overlaying text on image, brightening, increase
contrast, make grayscale, etc. But the user would want to execute a number
of actions on the same image, for eg., add a copyright string on the image
and draw a blue border or 5 pixel thickness. If we have independent tags for
each of the actions we would not be able to have one image with both these
effects. Hence we need a provision to specify a set of actions on the same
image.
The tag format which we specify should be generic enough so that any new
actions/ manipulations added later could also be used. Each action may have
any number of parameters, for eg., one action may need only one string while
other may need three (r, g & b) values.
The first solution that comes to my mind is to have generic tag for the
image and nested tags for the actions which in turn has nested tags for
parameters. Nested tags are better since any number can be specified.
eg.
<img:image fileName="somefile_in_the_domain.gif" > <!-- can be a file or
folder -->
<img:action name="contrast">
<img:param name="amount" value="10" />
</img:action>
<img:action name="border">
<img:param name="thickness" value="5" />
<img:param name="color" value="125" />
</img:action>
<img:action name="text-overlay">
<img:param name="string" value="some text" />
<img:param name="alignment" value="bottom" />
<img:param name="fontName" value="serif" />
<img:param name="fontSize" value="8" />
</img:action>
</img:image>
The name-value parameters will be stored in the parent tag (prefixed with
some text to make it unique) which will be finally
be converted to a set of name value pair parameters in the image src url.
for eg., <img
src="/servlets/ImageServlet?action1=contrast&contrast_amount=10&action2=bord
er&border_thickness=5&border_color=125&...." >
The Image servlet can create a hashtable with these name-value pairs. Based
on each of the action values a corresponding Image manipulation class is
instantiated and the hashtable is passed to it. The class takes relevant
information from the hastable and manipulates the image. Once done, the
servlet returns/ streams back the new image.
Errors may be thrown in the Image manipulation class due to insufficient
data, missing paramaters, etc..
However the tags remain the same and more Image manipulation classes can be
added later.
Something like the one given above should be adopted. Any suggestions??
All those who are good at OOAD, please comment.
Abey M. Mullassery
e: abey@mullassery.com
w: http://www.Mullassery.com
====================================
Live; Don't just exist.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Generic Tags for Image Tag Actions
Posted by Abey Mullassery <ab...@mullassery.com>.
We can have generic tags such as
<img:action name="contrast">
<img:param name="amount" value="10" />
The advantage in the above case is that no more tags are necessary.
These generic ones will work for all actions.
To add a new action, all we need to add is the ImageAction Class only.
The disadvantage is that it has very poor validation.
Errors are detected only when trying to generate images.
OR we can have specific tags (for nested action tags only) such as
:> <img:contrast value="10"/>
:> <img:border width="5" color="#888888"/>
:> <img:text value="Text!" valign="bottom" font="serif" size="8"/>
Here is advantage is the tighter specification where the tag specification
will force some required parameters.
However we will have to add tags for each action (not a great task though)
I am for Shawn's following modification too...
Web designers know colors in a hex format and we could reuse many keywords
from html itself for our tags too.
Bob,
http://www-106.ibm.com/developerworks/java/library/j-jsptags.html
was a relevant article.
:> Other, more minor included modifications:
:> - more HTML-like attribute names (e.g., "width" instead of "thickness")
:> - HTML-style color specification ("#888888" instead of "125")
:>
It is also better to iterate through the folder than specifying a whole
folder of images in a tag.
:> Also, what do you mean by "can be a file or folder"? If we want
:> thumbnailing as a particular feature, I'd suggest that be a specific tag,
:> or perhaps an explicit iteration (using JSTL):
:>
:> <file:directory path="/foo" var="dir">
:> <c:forEach items="$dir" var="file">
:> <img:thumbnail src="$file"/>
:> </c:forEach>
:>
I would like to know what all of you think.
Please post your comments too..
Abey M. Mullassery
e: abey@mullassery.com
w: http://www.Mullassery.com
====================================
Live; Don't just exist.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Generic Tags for Image Tag Actions
Posted by Shawn Bayern <ba...@essentially.net>.
Hi again! A handful of thoughts --
I would suggest decoupling the interface with the page author from the
back-end implementation. In almost all cases, the implementation can
adapt to whatever interface is deemed appropriate.
As for what the tags should look like...
> The first solution that comes to my mind is to have generic tag for the
> image and nested tags for the actions which in turn has nested tags for
> parameters. Nested tags are better since any number can be specified.
This is certainly one viable option. I would suggest two modifications to
the design you proposed. First, instead of <img:param> tags, most
individual parameters could be tag attributes. This is just aesthetic;
it's more concise. Second, why a single <img:action name="..."> tag
versus individual action tags: <img:contrast>, <img:border>, and so on.
Here's a picture of "before" and "after:
You suggested:
> eg.
> <img:image fileName="somefile_in_the_domain.gif" > <!-- can be a file or
> folder -->
>
> <img:action name="contrast">
> <img:param name="amount" value="10" />
> </img:action>
>
> <img:action name="border">
> <img:param name="thickness" value="5" />
> <img:param name="color" value="125" />
> </img:action>
>
> <img:action name="text-overlay">
> <img:param name="string" value="some text" />
> <img:param name="alignment" value="bottom" />
> <img:param name="fontName" value="serif" />
> <img:param name="fontSize" value="8" />
> </img:action>
>
> </img:image>
With my modifications, this would become:
<img:file path="somefile.gif">
<img:contrast value="10"/>
<img:border width="5" color="#888888"/>
<img:text value="Text!" valign="bottom" font="serif" size="8"/>
</img:file>
Other, more minor included modifications:
- more HTML-like attribute names (e.g., "width" instead of "thickness")
- HTML-style color specification ("#888888" instead of "125")
Also, what do you mean by "can be a file or folder"? If we want
thumbnailing as a particular feature, I'd suggest that be a specific tag,
or perhaps an explicit iteration (using JSTL):
<file:directory path="/foo" var="dir">
<c:forEach items="$dir" var="file">
<img:thumbnail src="$file"/>
</c:forEach>
> The name-value parameters will be stored in the parent tag (prefixed with
> some text to make it unique) which will be finally
> be converted to a set of name value pair parameters in the image src url.
> for eg., <img
> src="/servlets/ImageServlet?action1=contrast&contrast_amount=10&action2=bord
> er&border_thickness=5&border_color=125&...." >
>
> The Image servlet can create a hashtable with these name-value pairs.
Again, this involves reworking the servlet for each new image tag.
Everyone who wants to add an image tag needs their hands in the servlet
too.
Now, the alternative, as I believe Tim suggested, is to reverse the order
and let the tags nest the other way; each image tag acts as a "filter" for
its body. This alternative is certainly viable, but I believe it leads to
somewhat more complex syntax: the "outer" tag should jump out at the page
author as the action being performed, not just a final filter.
Furthermore, we've got just one level of nesting here, and the alternative
would require arbitrary depth for successive filters.
Shawn
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Generic Tags for Image Tag Actions
Posted by Abey Mullassery <ab...@mullassery.com>.
:>
:> <img:label text="(c) Me" orientation="90" position="left" length="100%">
:> <img:action name="size" percent="25">
:> <img:action name="contrast" value="10">
:> <img:image src="afile.gif"/>
:> </img:action>
:> </img:action>
:> </img:label>
:>
:> In this was you could control the order of processing... the
:> example above
:> would adjust the contrast then change the size then add a label.
:>
The order could be specified by the order of the nested action tags inside
the image tag.
:> I'm not sure how this would affect the servlet processing, though.
:>
The html <img> tag is printed out by one of the jsp tag handlers.
We are discussing 2 scenarios. (pl. read earlier mails)
In Scenario 1
If the Servlet is supposed to generate the dynamic image, then the Tag
handler need to pass all the info, along with img src url. This is best
handled by one and the same handler class and hence the choice becomes the
outermost tag since data from all nested tags can be easily passed to the
parent tag. The main image tag is compulsory and hence is the best to be the
outermost tag while the actions may or may not be there. Moreover if each
action tag spec is different from the another, generating a url will be more
complicated. But each specific action tag handler can generate its required
url parameter and pass it to the parent tag. One has to be finalized....
suggestions please....
In Scenario 2
It will work fine if the Tag Handler is supposed to generate the dynamic
image, the data/ dynamic image has to be passed to the parent tags. However
this has a few other disadvantages as mentioned in the earlier mails.
:> Don't forget that all the other attributes of the normal html <img/> tag
:> have to be passed through, e.g. border, style and align.
:>
True, our image tag should also have these attributes too, even though they
are just added without any change in the resulting html <img> tag.
Any suggestions?
Abey M. Mullassery
e: abey@mullassery.com
w: http://www.Mullassery.com
====================================
Live; Don't just exist.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Generic Tags for Image Tag Actions
Posted by Tim Squires <js...@cheekymail.net>.
Just another thought...
<img:label text="(c) Me" orientation="90" position="left" length="100%">
<img:action name="size" percent="25">
<img:action name="contrast" value="10">
<img:image src="afile.gif"/>
</img:action>
</img:action>
</img:label>
In this was you could control the order of processing... the example above
would adjust the contrast then change the size then add a label.
I'm not sure how this would affect the servlet processing, though.
Don't forget that all the other attributes of the normal html <img/> tag
have to be passed through, e.g. border, style and align.
-----Original Message-----
From: Abey Mullassery [mailto:abey@mullassery.com]
Sent: 05 December 2001 09:45
To: Tag Libraries Developers List
Subject: Generic Tags for Image Tag Actions
Right now we talked about developing tags for specific actions on images
such as make thumbnail, overlaying text on image, brightening, increase
contrast, make grayscale, etc. But the user would want to execute a number
of actions on the same image, for eg., add a copyright string on the image
and draw a blue border or 5 pixel thickness. If we have independent tags for
each of the actions we would not be able to have one image with both these
effects. Hence we need a provision to specify a set of actions on the same
image.
The tag format which we specify should be generic enough so that any new
actions/ manipulations added later could also be used. Each action may have
any number of parameters, for eg., one action may need only one string while
other may need three (r, g & b) values.
The first solution that comes to my mind is to have generic tag for the
image and nested tags for the actions which in turn has nested tags for
parameters. Nested tags are better since any number can be specified.
eg.
<img:image fileName="somefile_in_the_domain.gif" > <!-- can be a file or
folder -->
<img:action name="contrast">
<img:param name="amount" value="10" />
</img:action>
<img:action name="border">
<img:param name="thickness" value="5" />
<img:param name="color" value="125" />
</img:action>
<img:action name="text-overlay">
<img:param name="string" value="some text" />
<img:param name="alignment" value="bottom" />
<img:param name="fontName" value="serif" />
<img:param name="fontSize" value="8" />
</img:action>
</img:image>
The name-value parameters will be stored in the parent tag (prefixed with
some text to make it unique) which will be finally
be converted to a set of name value pair parameters in the image src url.
for eg., <img
src="/servlets/ImageServlet?action1=contrast&contrast_amount=10&action2=bord
er&border_thickness=5&border_color=125&...." >
The Image servlet can create a hashtable with these name-value pairs. Based
on each of the action values a corresponding Image manipulation class is
instantiated and the hashtable is passed to it. The class takes relevant
information from the hastable and manipulates the image. Once done, the
servlet returns/ streams back the new image.
Errors may be thrown in the Image manipulation class due to insufficient
data, missing paramaters, etc..
However the tags remain the same and more Image manipulation classes can be
added later.
Something like the one given above should be adopted. Any suggestions??
All those who are good at OOAD, please comment.
Abey M. Mullassery
e: abey@mullassery.com
w: http://www.Mullassery.com
====================================
Live; Don't just exist.
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>