You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Michael Westbay <we...@seaple.icc.ne.jp> on 2000/12/22 13:35:34 UTC
form:img
Hi all,
I whipped together an IMG (form:img) tag real quick. I know that the
form:image tag will work, but that really wasn't what I wanted.
This is by no means complete. I didn't include any JavaScript event
handlers, and all of the attributes aren't implemented in the output
either. It was just a start to get something out there.
The following needs to be added to the src/doc/struts-form.xml file:
------ start ------
<tag>
<name>img</name>
<summary>Render an HTML image</summary>
<tagclass>org.apache.struts.taglib.form.ImgTag</tagclass>
<info>
<p>Renders an HTML <code><img></code> element.</p>
</info>
<attribute>
<name>src</name>
<required>false</required>
<rtexprvalue>true</rtexprvalue>
<info>
<p>Logical name of a global <code>src</code> that
contains the actual content-relative URI of the image.
</p>
</info>
</attribute>
<attribute>
<name>alt</name>
<required>false</required>
<rtexprvalue>true</rtexprvalue>
<info>
<p>The alternative text to display in the place of a
graphical image for browsers that chose to do so.</p>
</info>
</attribute>
<attribute>
<name>width</name>
<required>false</required>
<rtexprvalue>true</rtexprvalue>
<info>
<p>The display width of the image.</p>
</info>
</attribute>
<attribute>
<name>height</name>
<required>false</required>
<rtexprvalue>true</rtexprvalue>
<info>
<p>The border size around the image (often visible
when embedded in a link).</p>
</info>
</attribute>
<attribute>
<name>name</name>
<required>false</required>
<rtexprvalue>true</rtexprvalue>
<info>
<p>The name of a JSP bean that contains a <code>Map</code>
representing the query parameters (if <code>property</code>
is not specified), or a JSP bean whose property getter is
called to return a <code>Map</code> (if <code>property</code>
is specified).</p>
</info>
</attribute>
<attribute>
<name>property</name>
<required>false</required>
<rtexprvalue>true</rtexprvalue>
<info>
<p>The name of a property of the bean specified by the
<code>name</code> attribute, whose return value must be
a <code>java.util.Map</code> containing the query parameters
to be added to the hyperlink. You <strong>must</strong>
specify the <code>name</code> attribute if you specify
this attribute.</p>
</info>
</attribute>
<attribute>
<name>scope</name>
<required>false</required>
<rtexprvalue>true</rtexprvalue>
<info>
<p>The scope within which to search for the bean specified
by the <code>name</code> attribute. If not specified, all
scopes are searched.</p>
</info>
</attribute>
</tag>
------ end ------
The home page said that this was the place to post code for consideration
to be incorporated. The list hasn't been very active, so I haven't seen
if there's a more formal method to submitting, yet.
As I said, this was just a tag I whipped up real quick to get the job done.
I imagine that it could use a bit of refining before being incorporated.
But and IMG and a INPUT TYPE="IMAGE" are really two different things, and,
IMHO, should be treated as such.
I hope somebody else finds this useful.
--
Michael Westbay
Work: Beacon-IT http://www.beacon-it.co.jp/
Home: http://www.seaple.icc.ne.jp/~westbay
Commentary: http://www.japanesebaseball.com/
Re: RFC: An enhanced img tag - Was: form:img
Posted by Ted Husted <ne...@husted.com>.
On 12/22/2000 at 4:39 PM Matthias Kerkhoff wrote:
> It could determine the actual image dimensions and dynamically insert
them into the generated
HTML stream
> (Read: Please addyour comments or additional suggestions. :)
Comments:
If this is done dynamically, are we not just moving the work from the
client to the server?
Doesn't the browser do essentially the same thing, only later in the
cycle?
The page may be drawn "smoother", but I would wonder if it would be
drawn faster.
Additional suggestions: (sorry, but you asked ;-)
The other thing I'm wondering about is all the other page-presentation
maintenance nightmares. Cascading Style Sheets, like Javascript, are a
great thing, but the implementation differences between vendors can
drive you mad.
For discussion purposes, FrontPage uses a very effective authoring
model. The editor generates things like the image tags for you
dynamically at edit-time. These are then saved statically in the page,
so there is no overhead when the browser retrieves it.
It also uses a similar model for "lazy includes". The HTML is inserted
in the page, but with scripting comments (Javascript style) so it can
be refreshed later. In the background, FrontPage checks its list of
scheduled includes, and automatically updates the components as
necessary. But it does not read the file being included with each
request. At most, it parses the tags hidden in HTML comments. If a
change is necessary, it updates the HTML and saves the page back to the
Web (a permanent cache, you could say).
A similar model is also used for things like substitution strings, so
you can insert your phone number all over your Web, and then change it
all at once (say, if the area code changes, like mine will soon).
The key thing here is that the changes are not dynamic. The HTML is
already there and can be read by any browser with or without the
server's help. But, FrontPage tracks where automatic changes can be
made, and makes them, batch style, only when needed.
This is something like the JSP model, where the container only
recompiles the page when there has been a change.
Personally, I think it would be cool to see this model applied to a Web
application somehow, so I could specify all sorts on things in my HTML
(headings, fonts, image dimensions, table widths, lazy includes), but
write them into the HTML in an updateable, static form. Then you have
the best of both worlds, dynamic updating and static efficiency.
Here' s an example from a FrontPage file
<p>
<!--webbot bot="Substitution" S-Variable="Telephone" startspan -->716
425-0252<!--webbot bot="Substitution" endspan i-checksum="12969" -->
</p>
A generic implemention might include a helper application that would
scan JSPs (and/or HTML pages) looking for it's landmark tags (enclosed
in HTML comments), and then update the HTML against a resource. So, if
the design team changed the image, they might bring up a GUI, look up
the image by HTML name or filename, and commit the change. The GUI
could then run around and update the HTML between the landmark comment
tags. (Something like Tidy HTML does.) Of course, the GUI might just be
a convenient way of updating a XML, and then running a simple Java app,
which someone could also do by hand.
(For extra credit, it might even check on dependant class files, and
touch JSPs as needed ;-)
Not anything like what you suggested, but I thought I would mention the
idea.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/
RFC: An enhanced img tag - Was: form:img
Posted by Matthias Kerkhoff <ma...@BESToffers.de>.
> I whipped together an IMG (form:img) tag real quick. I know that the
> form:image tag will work, but that really wasn't what I wanted.
> [...]
> But and IMG and a INPUT TYPE="IMAGE" are really two different things, and,
> IMHO, should be treated as such.
Yes, IMG and INPUT type=image _are_ different. I've also thought about an
img tag and have an additional idea how an img tag could be used to add
some value for the JSP developer. I have not yet started with implementing
it, because the tag doesn't have top priority for my site.
I would like to discuss the basic idea with and get some feedback on it
from the list before I start with the implementation. (Read: Please add
your comments or additional suggestions. :)
Matthias
The problem:
------------
To speed up client-side-layout and page presentation, most browser vendors
suggest that the width- and height- attributes should be present as part
of the img tag. This allows the browser to compute the final page layout
without having to look at the actual image dimensions, (i.e. the layout
may be done before the images are loaded from the net _and_ the browser
is assured that it doesn't have to re-layout the page, after the image
download has finished)
However, hard-coding the image dimensions in the page may lead to a
maintenance nightmare, especially if image designers/producers and the
JSP-developers are in different teams or if the images are generated
on the fly. Hard-coding the image dimensions will also reduce the
ability to use the page as a template, if the actual images are
variable (i.e. part of the template attributes).
A possible solution:
--------------------
IMHO, the img tag could be used to solve this dilemma. It could determine
the actual image dimensions and dynamically insert them into the generated
HTML stream (of course only if it is directed to do so, for example by
some other boolean attribute.)
Things to be aware of:
----------------------
(Need for a cache)
Touching the image file on every request to determine it's dimensions would
be far to expensive. Thus, the img tag should use/store/check a cache with
already determined image dimensions using the absolute img URL as a key.
Regarding the cache, the usual drawback between memory requirements and speed
exists: If the cache is part of the application context, there will be a
slowdown due to the necessary synchronization, while keeping the cache in
the session context would probably lead to increased memory consumption
that may in turn also lead to an unacceptable slowdown of the site.
(On the fly images)
Caching may not work for on-the-fly generated images with varying image
dimensions (Is this a real-life problem ?). On-the-fly images may lead a
performance hit for cache-misses, because the image will be generated
twice (once to get the image dimensions and once to send the image to
the client.) Depending on the cost of producing the image this may be
unacceptable. If requesting the image has side effects, the double request
on cache-misses may also lead to unexpected results. Think of an ad-server
that uses the requests to do some kind of accounting...
Alternative solution:
---------------------
Instead of generating image dimensions on a per-tag base another solution
would be to add a single tag - say <dimensions> - to the <head> section.
This tag could output a <style> block to the page's <head> section,
containing all image dimensions keyed by the image's id, probably reducing
the runtime overhead at the server-side to a single tag invocation
instead of multiple tag/cache-lookup invocations.
I'm not sure, how this hypothetical <dimensions>-tag would get the
information on the specific img's for which it should retrieve and print
the dimensions. Any ideas ?
RFC: An enhanced img tag - Was: form:img
Posted by Matthias Kerkhoff <ma...@BESToffers.de>.
> I whipped together an IMG (form:img) tag real quick. I know that the
> form:image tag will work, but that really wasn't what I wanted.
> [...]
> But and IMG and a INPUT TYPE="IMAGE" are really two different things, and,
> IMHO, should be treated as such.
Yes, IMG and INPUT type=image _are_ different. I've also thought about an
img tag and have an additional idea how an img tag could be used to add
some value for the JSP developer. I have not yet started with implementing
it, because the tag doesn't have top priority for my site.
I would like to discuss the basic idea with and get some feedback on it
from the list before I start with the implementation. (Read: Please add
your comments or additional suggestions. :)
Matthias
The problem:
------------
To speed up client-side-layout and page presentation, most browser vendors
suggest that the width- and height- attributes should be present as part
of the img tag. This allows the browser to compute the final page layout
without having to look at the actual image dimensions, (i.e. the layout
may be done before the images are loaded from the net _and_ the browser
is assured that it doesn't have to re-layout the page, after the image
download has finished)
However, hard-coding the image dimensions in the page may lead to a
maintenance nightmare, especially if image designers/producers and the
JSP-developers are in different teams or if the images are generated
on the fly. Hard-coding the image dimensions will also reduce the
ability to use the page as a template, if the actual images are
variable (i.e. part of the template attributes).
A possible solution:
--------------------
IMHO, the img tag could be used to solve this dilemma. It could determine
the actual image dimensions and dynamically insert them into the generated
HTML stream (of course only if it is directed to do so, for example by
some other boolean attribute.)
Things to be aware of:
----------------------
(Need for a cache)
Touching the image file on every request to determine it's dimensions would
be far to expensive. Thus, the img tag should use/store/check a cache with
already determined image dimensions using the absolute img URL as a key.
Regarding the cache, the usual drawback between memory requirements and speed
exists: If the cache is part of the application context, there will be a
slowdown due to the necessary synchronization, while keeping the cache in
the session context would probably lead to increased memory consumption
that may in turn also lead to an unacceptable slowdown of the site.
(On the fly images)
Caching may not work for on-the-fly generated images with varying image
dimensions (Is this a real-life problem ?). On-the-fly images may lead a
performance hit for cache-misses, because the image will be generated
twice (once to get the image dimensions and once to send the image to
the client.) Depending on the cost of producing the image this may be
unacceptable. If requesting the image has side effects, the double request
on cache-misses may also lead to unexpected results. Think of an ad-server
that uses the requests to do some kind of accounting...
Alternative solution:
---------------------
Instead of generating image dimensions on a per-tag base another solution
would be to add a single tag - say <dimensions> - to the <head> section.
This tag could output a <style> block to the page's <head> section,
containing all image dimensions keyed by the image's id, probably reducing
the runtime overhead at the server-side to a single tag invocation
instead of multiple tag/cache-lookup invocations.
I'm not sure, how this hypothetical <dimensions>-tag would get the
information on the specific img's for which it should retrieve and print
the dimensions. Any ideas ?