Hey folks,
I've been thinking about venturing into writing my own taglib.
Are there any hardcore taglib types here I could bounce a few
questions off of?
Is there a good mailing list for this sort of thing? There's the
jakarta taglib mailing lists (users and developers), but I'm not sure
how acceptable a general taglib question would be there.
The specific reason I'm thinking of looking into this is that I
want to write a generic form processor utility, as an alternative to
using one-off javabeans for each form, much like the Form Processing
API (http://www3.sympatico.ca/iostro/fpapi2.0/). I'm not yet sure I
want to build on the FPAPI, mainly because the FPAPI seems to have a
strong emphasis on generating the form HTML, and I'd like to side-step
that and just focus on the processing of the form submit.
My two main goals are
1) to make something that's very, very easy to use, with additional
features that are very, very easy to add in without much hassle,
2) to make something that you can use without having to adopt a way of
life.
See the notes at the end for my planned design.
One issue that's always bugged me is the need to have multiple
files containing the same structure of information - the form input
tags in the page, and the JSP, or servlet, or javabean, or
form-processor config file to parse the form submit. Two files means
two places where each change has be made, means twice as many
opportunities for mistakes.
What I'm hoping I can figure out how to do, using a custom
taglib, is set up the tags so that the JSP itself is the config file
that drives the form processor. I suspect this may be a tight fit; I
can envision how I'd write this if I were just treating the JSP source
as an XML file, loading it, parsing it, and processing the XML tags.
I'm wondering if that's doable with taglibs.
One idea is that the taglib would have a full set of equivalent
HTML form tags, whose effects are identical to the standard <INPUT>,
<SELECT>, etc, tags, except that they can also contain attributes that
define the formprocessor. I'm not sure whether that's a kludge or a
feature; I'd hate to have to maintain the whole <FORM> tag set, but
it'd be nice if the formprocessor tags were smoothly integrated with
the regular HTML tags.
Instead of:
<TR>
<TD>Foo</TD>
<TD><INPUT name="foo" type="text" value="<%= beanname.getFoo() %>">
<FONT fontcolor="red"><%= beanname.getFooError() %></FONT>
</TD>
</TR>
You'd have:
<TR>
<TD>Foo</TD>
<TD><FP:INPUT name="foo" type="text"/>
<FP:ERROR name="foo"/>
</TD>
</TR>
And then, adding a few more features (see below), you might have:
<TR>
<TD>Foo</TD>
<TD><FP:INPUT name="foo" type="text" paramtype="integer" default="bar">
<FP:TEST type="range" lower="1" upper="10"/>
</FP:INPUT>
<FP:ERROR name="foo"/>
</TD>
</TR>
Form Processor Design
My plan is an xml config file driven approach that defines a tree
of objects to be instantiated (with arguments):
formprocessor
formhandler
parameter
test
parameter
test
parameter
test
parameter
test
test
test
test
(Note: some might point out that there're a bunch of objects in
that tree, but I have a couple of strategies for handling that. For
one thing, object overhead has gone down a lot in recent versions of
java. However, if it's still an issue, then I'd switch to using a
thread-safe version of the tree and each encapsulating each request
would be encapsulated in a visitor that then traverses the tree.)
The formprocessor itself would have a fairly straightforward
formprocessor.mapper() method, which takes the request object as an
argument and simulates <jsp:setProperty property="*">. Then
formprocessor.process() (or whatever) gets called and it loops through
the parameters, invoking each of the parameter's tests on the
parameter. The tests themselves can be stacked in a tree of tests,
though I don't want to go too far in that direction - if you need
something that complicated, now it's time to write a custom test
class.
The formprocessor would also have a few standard methods for
getting the data back out in useful formats (as an XML document, as
various useful chunks of SQL, suitable for building UPDATE or INSERT
statements, etc).
The tests have an isValid() method, and a getErrorMessage()
method, as well as user-configurable error message, with (eventually)
a string substitution similar to java MessageFormat or C's printf().
Finally, when it's time to actually do something with that data,
invoke formprocessor.handle() and it fires off the form handler.
Add to that:
A set of boilerplate parameter classes with code for handling and
parsing various parameter types.
A set of boilerplate test classes with code for various typical
tests (greater than, less than, one of a set, etc).
A set of boilerplate form handler objects with code for commonly
requested form handling, for example emailing the data; saving
it to a database; HTTP POSTing it off to another server; sending
a JMS message, etc.
Steven J. Owens
[EMAIL PROTECTED]
"I'm going to make broad, sweeping generalizations and strong,
declarative statements, because otherwise I'll be here all night and
this document will be four times longer and much less fun to read.
Take it all with a grain of salt." - Me at http://darksleep.com
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant archives, FAQs and Forums on JSPs can be found at:
http://java.sun.com/products/jsp
http://archives.java.sun.com/jsp-interest.html
http://forums.java.sun.com
http://www.jspinsider.com
