jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eduardo Pelegri-Llopart <Eduardo.Pelegrillop...@Sun.COM>
Subject Re: [OT]: Compile time tags. (XSLT preprocessing of JSP)
Date Thu, 22 Mar 2001 15:54:17 GMT
James says...

> I'm happy to experiment :)

As long as you don't stop playing with your other ideas, I'm happy too!
:-). In particular, have you looked into adding SAX streams to your
pipes?  That seems a natural extension...

> For example right now in JSP 1.2 the TagLibraryValidator returns a String if
> there is an error while validating the whole page. Returning an XML document
> would be a better idea, as multiple errors could be returned easily. e.g.
> 
> <jsp:errors>
>     <jsp:error line="20" column="5" tag="foo:bar">
>         Missing attribute "d"
>     </jsp:error>
>     <jsp:error line="40" column="2" tag="foo:foo">
>         This tag should be nested inside a <foo:c> tag
>     </jsp:error>
> </jsp:errors>

That is an interesting idea.  Debugging info is one area that we have
not been spending much time on, and which can use it!

> ... different pipeline ideas...

If you do things like reordering the input substantially (like moving
things form beginning to end) pipelines don't really work as such...

Effective debugging in the presence of source transformations is a hard
issue.  The problem has been explored for a long time in language
design, and, IHMO, has not been solved sucesfully.

	- eduard/o

James Strachan wrote:
> 
> Thanks for your comments Eduardo & Jeff - I've found your thoughts
> enlightening.
> 
> From: "Eduardo Pelegri-Llopart" <Eduardo.Pelegrillopart@Sun.COM>
> 
> > Anyhow, as I said, I am interested in seing experimentation with the
> > concept.
> 
> I'm happy to experiment :)
> 
> > If somebody wants to try it, I would design it as a
> > transformation class that is delivered with a Tag Library (in a way
> > similar to that of TagLibraryValidator).  I guess I would try adding
> > methods to get a DOM or a JDOM out from a PageData, and have the
> > transformer class work on it.
> 
> There are a variety of ways of working with XML in Java. There's SAX, DOM,
> JDOM and DOM4J then there's a whole host of XML <-> Java data binding
> techniques from Adelard (if it ever gets released) through to Koala to
> Castor and many others.
> 
> I'd prefer any XML preprocessing API hook to be based purely on SAX. It is
> the most widely used SAX API and sits underneath most other XML tools (like
> all of the above). Then any other XML technology can be used on top of SAX.
> 
> SAX already has the concept of plug in preprocessors - its called XMLFilter.
> An XMLFilter implementation could do a full XSLT transformation, it could
> build a DOM / JDOM / DOM4J tree and do something with it in regular Java
> code, or could just do some simple Java code to expand or preprocess a
> 'compile time tag' using SAX.
> 
> http://www.megginson.com/SAX/Java/javadoc/org/xml/sax/XMLFilter.html
> 
> Jasper right now already uses SAX to parse the XML JSP, so it would be
> fairly trivial to allow a configurable XMLReader to preprocess SAX events
> before the JSP code gets generated.
> 
> If we made the API / deployment descriptor hook that a web-app could have
> its own 'XMLFilter' from the API perspective then taglib implementators
> could use whichever tool they are happy with from DOM, DOM4J, JDOM, Castor,
> Adelard or just use XSLT with a standard 'XSLFilter' implementation of
> XMLFilter.
> 
> Maybe a tag library could be defined as having either an XSL stylesheet
> associated with it (as I can see that as an easy and common way for taglib
> developers to pre-process the JSP) or a Java XMLFilter class.
> 
> A JSP compiler could group all the XSL stylesheets for each tag library
> together into a single stylesheet per web-app (using <xsl:import>) and chain
> together any tag libraries XMLFilter class objects when it does the JSP
> compile.
> 
> It might be useful to use the same mechanism for JSP/XML validation and XML
> pre-processing. Both could be implemented via SAX pipelining / filtering.
> 
> For example right now in JSP 1.2 the TagLibraryValidator returns a String if
> there is an error while validating the whole page. Returning an XML document
> would be a better idea, as multiple errors could be returned easily. e.g.
> 
> <jsp:errors>
>     <jsp:error line="20" column="5" tag="foo:bar">
>         Missing attribute "d"
>     </jsp:error>
>     <jsp:error line="40" column="2" tag="foo:foo">
>         This tag should be nested inside a <foo:c> tag
>     </jsp:error>
> </jsp:errors>
> 
> Then by the time the "preprocessing" stage has taken place, any <jsp:errors>
> SAX events found would halt the JSP compilation step and do something
> sensible with the errors. (Making the errors XML would make it easier for
> tool vendors, Allaire, Macroedia et al to do sensible things in their
> editors).
> 
> > > The neat thing about XML+XSLT approach is that one can (potentially)
> validate
> > > the generated XML after each taglib has been applied. Each taglib can
> have
> > > an XML Schema (or TReX or whatever) associated with it, and this can,
> with
> > > great preciseness, validate that the JSP/XSP is valid at that point.
> 
> Exactly!
> 
> There are a variety of validation techniques and tools out there (I like
> Schematron too). All could be intergrated together easily via SAX filtering.
> This would also avoid multiple reparses of the "page data" by different tag
> libraries.
> 
> > The TagLibraryValidator that we have added in JSP 1.2 is intended to
> > help with validation of the generated content.  But we do not have much
> > experience with it yet.  The hard part, of course, is that what you want
> > to validate is not the JSP but the output of the JSP (and ditto for the
> > XSP), and whenever there is some dynamic content gnerated one needs to
> > make some assertions about what shape it has.  In that, I think that
> > whenever one drops into raw java code (be it JSP scriptlets or XSP java
> > fragments) it is very hard to analyse what is happening.
> 
> Agreed. A simple way of plugging in XML validation or preprocessing seems to
> make sense - and SAX seems the right way forward to me.
> 
> <James/>
> 
> James Strachan
> =============
> email: james@metastuff.com
> web: http://www.metastuff.com
> 
> __________________________________________________________________
> 
> If you are not the addressee of this confidential e-mail and any
> attachments, please delete it and inform the sender; unauthorised
> redistribution or publication is prohibited.
> Views expressed are those of the author and do not necessarily
> represent those of Citria Limited.
> __________________________________________________________________

Mime
View raw message