Testing under Tomcat 3.3
I tested the component under Tomcat 3.3 on both Redhat Linux 7.2 and Windows 2000.
Here are some suggestions to do a quick test of the component in your environment.
Create a directory under webapp called reportTag. Extract the source code for ReportWriter tag under this directory.
Configure a datasource. I tested using MySQL and Access. You can import the file called Resource.txt in the reportTag directory into you favorite database product. I also have two versions of web.xml -- one for Access; one for MySQL.
Make sure the datasource works by running the Datasource.jsp. This example does a simple "select * from resource" and does no Example formatting. If this JSP doesn't work, you may have a database connection problem.
Test the other jsps. When these are working, you have a working base for your own development.
Recently, I have been working on a project where it was required to
display grid-type data from database tables.
Right now the words "Report Writer" kind of spring to mind, although, as
it turned out, HTML tables could easily handle the data display and,
actually, allowed for certain types of customization that you could
hardly expect in a Report Writer product..
To solve the problem, particularly since the web application was
deployed on a JSP 1.0 application server, I developed a Bean that would
accept a brief number of parameters (a SELECT statement being the main
one) and format the data by merging a ResultSet object with a number of
pre-set HTML tags. .
Since the HTML was all constructed in Java code, I developed a scheme
whereby the major formatting elements could be embedded in a property
file which the Bean's formatter would read and apply. Of course, this
goes against all the articles you will read about MVC architecture and
divorcing the presentation layer from the Java database/business logic.
However, in the circumstance, it did work and I was able to code
everything pretty quickly..
Despite everything you will read today about putting together JSP
presentation code with Java database/business logic, the major issue of
the design I describe above is that it works well in one scenario: if
the JSP developer is a seasoned Java pro. If the HTML template required a
change, I could easily
document the how-to. In fact, I believe that a large number of projects
you will find today are just like mine: a group of JSP developers are
really either Java pros or Java wannabes. Therefore, they have no
problem tweaking the code.
However, when the JSP developer is not a Java developer, the whole thing
falls down. And, in reality, I will admit that if JSP is going to grow
as a means of connecting HTML to backend logic, we will start seeing
more and more JSP developers that don't know and don't care..
Enter the tag library
Since about JSP 1.1, the use of tags mixed with HTML/JSP code has become
a more attractive and fully-featured means of connecting the dots
between layers of development. There are a number of web development
products out there, like ColdFusion, that have already figured this one
out. The developer passes in a brief, simple message and gets a whole
bunch of functionality from some back-end API.
Unlike the UseBean tag that I applied for my project, tags are now able
to read and pass along various application variables from the web.xml
configuration file. Therefore, whereas my UseBean has to understand how
to look up database connection info, this data can now be stored in the
servlet application's web.xml and passed along to any layer that has
access to the JSP's PageContext object.
Tags are also now capable of scanning portions of the HTML and handing
it off to the tag layer. This is an important feature in my mind because
in my original design, I would have liked to let the JSP developer give
me a template file that actually was an HTML table. The goal: let the
JSP side say "format the report like this table...".
Tags, tags, tags...
Using JSP 1.1 tag capability, I decided let the JSP side present
a mock-up for the report right on the page in the form of an HTML table.
The tag logic could then parse through the example table, figure out
items like column headers and split the table into formatting segments
and data segments. Then, as the tag code looped through the database
ResultSet, the template could be chunked appropriately.
To test the tag, I created tables in Dreamweaver, Websphere Studio and
Netscape navigator. The example below -- which actually doesn't display
too well in my Linux version of Netscape -- was created with Dreamweaver.
When you have questions regarding Java and security
including Books
JavaSofts JavaReel
This applications/applet showcase features a wide
variety of current Java products. You can view all the products listed
or a breakdown of products by market category.
Elliotte Rusty Harolds Cafe au Lait
Elliottes page of Java news and resources
10
Dave Central Software Archive
Daves site offers an abundance of Java-related
software
tools and resources
databases
JavaToys
This Java development resource center provides tons
of
useful links for Java developers
reference materials
Java Game Park
If youre into gaming
which has more than 200 free games online. Whether
youre an adventure fan or into sports
The JavaBoutique
features downloadable Java development environment
demos
how-to articles
Automated Software Mart
Bayside Computing
Java applets
The Applet Depot
This is the place to find applets such as Java poetry
magnets. It also includes demos of other applets and the possibility of
having a custom applet created just for you.
http://www.ericharshbarger.org/java/
There were a few problems with Visual designers. WebSphere Studio
outputs upper-case HTML tags, while the other two products output lower
case tags. Not a problem to the designer but a considerable nuisance to
the parsing routine.
On the whole, it seemed that I could throw considerably sophisticated
example tables at the tag and still get great results. Some features like
banded reports (where the back color of one row contrasts sharply against
the backcolor of it predecessor) are definitely do-able, but not in this
version.
How to construct a JSP report
Assuming you have everything installed correctly (I will walk through
this later...), the steps are straightforward:
Place the following at the top of the page:
< %@ taglib uri="../WEB-INF/jsp/javazoid.tld" prefix="j" %>
Note that the uri depends on where your JSP reside relative to the web
app. If you place your page in a JSP folder under the web app, this uri
will work. If you have a series of JSP folders, it might be easier to
use an abosolute path.
Insert a tag like this one:
where
j
is the variable referencing the tag prefix
reportwriter
is the tag name in the TLD file
datasource
is the string to indicate how to connect
to the database
using JDBC. In the web.xml file for my web app, I set up a number of
variables like
<context-param>
<param-name> mysqlAtHome.jdbc.driver
</param-name>
<param-value>
org.gjt.mm.mysql.Driver </param-value>
</context-param>
<context-param>
<param-name>
mysqlAtHome.jdbc.url </param-name>
<param-value>
jdbc:mysql://localhost:3306/javazoid </param-value>
</context-param>
<context-param>
<param-name>mysqlAtHome.jdbc.user
</param-name>
<param-value>app
</param-value>
</context-param>
<context-param>
<param-name>
mysqlAtHome.jdbc.password </param-name>
<param-value>matthew
</param-value>
</context-param>
<context-param>
This feature allows you to support multiple databases from the web app.
If you have only one data source, you might use "default" as a
datasource name, i.e., "default.jdbc.driver".
sqlKey
is a tag to identify a SQL statement or is
the SELECT statement
itself. You can create a entry in web.xml like
listAllResourcesselect * from resource
By entering "listAllResources" as the sqlKey, the tag knows how to find
the correct SQL. I added this feature because I have worked on a number of
projects with SQL embedded in many, many web pages and then seen panic
when the database changed.
If this feature isn't required, you can simply enter a SELECT statement
in the sqlKey variable (however, you can't use stored procedures this
way..yet).
startRow and endRow
are optional variable that you
can set in the Web
page only to indicate how many rows you want to see on the page. You
probably should set the endRow variable to something reasonable, but if
you don't, there is a default endRow of about 500. Sorry, I won't let
you dump and entire database into the browser... Also, remember that the
implementation of this feature is pretty basic. If, for some reason, you
need to set the startRow at 50,000 and endRow at 50,020, you might want
to look at how the source code implements this (in fact, you might wish
to have a stored procedure handle this....)
debug
if set to true, outputs what I figure a
developer needs to see
from the tag component.
Insert an HTML table. You need a two-row table -- one row for
the column headers; one row for the data. Format this table any way you
like, but remember to insert some non-tag data on the second row. Make
sure you create the same number of columns as the SQL statement requires.
I have created a number of examples in the source jar <> that
acompanies this package.
If you don't insert a valid table, the component will ignore your design
and format it in a plain-jane fashion. This feature was intended to
support "functionality in a hurry". In this case you can insert
something like "TABLE GOES HERE" between the tags.
End the tag with
</j:reportwriter>
Installing the component.
You need to understand how a JSP1.1/Servlet 2.2 web application works to
install the component. But I will outline the steps assuming minimal
knowledge.
I assume you have set up a directory in your "webapps" folder. I'll
call it reportTag for now.
You need a WEB-INF folder under reportTag. This folder will have
a web.xml file. See examples.
Store the taglib descriptor file, javazoid.tld, referenced in
WEB-INF/jsp.
Place the reportwritertag.jar file (which contains only class files... you can find it in
the WEB-INF/lib folder in the jar) in your
WEB-INF/lib directory.
I am assuming here that your database drivers are already set up in
the classpath. This seems to depend on how many apps reference the
driver's jar file. For this experiment, you might want to make sure that
the jar is in the classpath. If you see ClassNotFound errors, put it in
the WEB-INF/lib directory directory.
Copyright (c) 2002, Gervase Gallant gervasegallant@yahoo.com