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