A couple of ideas/options to think about: * There is a converter of the sort you suggest in the jakarta-watchdog-4.0 repository at Apache (in the org.apache.jspxml package under src/tools). This is used in Watchdog to make a copy of all the JSP-syntax test pages into XML syntax, to check identical functionality in either syntax.
* In JSP 1.2, there is the concept of a Validator that is fed (at compile time) a view of the page in XML syntax, no matter which syntax you started with. In the "exapmles" web app, there is a really simple Validator implementation that simply writes this out to System.out -- you might be able to adapt this. Craig McClanahan On Thu, 13 Dec 2001, Ragy Eleish wrote: > Date: Thu, 13 Dec 2001 13:09:24 -0800 > From: Ragy Eleish <[EMAIL PROTECTED]> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Subject: Proposal for a JSP to JSP Document (XML view of JSP) Converter > > Hi, > > I would like to propose the following (I tried to be as brief as possible): > > Proposal: > ------------- > Write a tool based on the Jasper code line to convert normal JSPs to the XML > view of JSPs (aka JSP Document). This tools should have a two modes; the > first one to convert any JSP to XML view of JSP. The second mode to convert > HTML+JSP to XHTML+JSP document, where it fixes all HTML tags incorrectness > and convert them to XHTML transient format (like an enhanced Tidy). > > Reason: > ------------ > JSP document has many benefits that include the ability to apply XSLT on the > pages to statically transform the pages to a different view. It could allow > some compile time checking of JSP page, which would save development time > for JSP writers. > Therefore to enhance the JSP document adoption, I thought that such a tool > would facilitate the migration to JSP documents. By allowing existing > applications to convert their normal JSPs automatically instead of the doing > that manually. > > Research: > -------------- > I did investigate Jasper code and found it doesn't implement a full fledged > parser, but it is written in a way to allow easy modifications. I wrote a > prototype of the converter. The main difficulty is that Jasper is not > written for customization, so factories may need to be added to it. > > Development: > ------------------- > I am going to build this tool for my company's internal use, and would be > actively maintaining it. We will perform QA on that tool in-house. I would > be great to get > > Time Frame: > ------------------ > I expect the initial version of the tool to take 3 to 4 weeks max worth of > development time. > > Open Questions: > ----------------------- > - Should this tool be a forked from Jasper code line or should Jasper be > modified to add customizations to it? > - Is that an acceptable proposal? If yes, who should I contact to commit to > code to CVS (since I don't have a commit status)? > > Regards > > ______________________________________________________________________ > Ragy Eleish [EMAIL PROTECTED] > Team Lead 650-232-5825 > Comergent Technologies http://www.comergent.com > 1201 Radio Road Fortune Magazine's 25 Coolest Companies 2001 > Redwood City, CA 94065 Crossroads 2001 A-List Award Winner > Upside's Hot 100 Private Companies Award 2000 > Cisco System's Supplier of the Year Award 1999 > > Comergent Technologies, Inc. is a leading provider of sell-side > business-to-business e-commerce software solutions that enable > enterprises to engage in collaborative commerce, fully leveraging > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
