Exactly!

I had the same discussion with Kin-man Chung who wrote most of jasper2. 
The spec explicitly disallows the stripping of whitespace and CR's.  To
maintain conformance and optimize the readability of generated output,
the spec should address these issues. Developers and users will never
see this problem if the pages don't use jsp tags.

As JSTL and custom tags become more popular, making the output more
readable and defining a consistent mechanism for handling this kind of
process should exist. Trying to debug hundreds of pages can get tiresome
on the eyes with bad formatting. Plug in your own story about poorly
formatted code/output.

peter lin


Martin Cooper wrote:
> 
> It seems to me that whether or not whitespace is "unwanted" depends on the
> content type being generated, and on the context within that content type.
> If you're generating text/plain, you might care about all of the whitespace
> being generated. If you're generating text/html, you might not care about
> whitespace most of the time, but you probably will care if you're trying to
> generate content inside <pre> blocks.
> 
> That's not to say that nothing can be done, but it throws some extra quirks
> into any potential solution. ;-}
> 
> --
> Martin Cooper
> 
> > -----Original Message-----
> > From: Peter Lin [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, July 09, 2002 6:29 PM
> > To: Tag Libraries Users List
> > Subject: stripping extra line feeds in choose tag
> >
> >
> >
> > hey shawn,
> >
> > I was looking into different ways of stripping extra
> > "\r\n" from the final output.  I thought of a way,
> > which is definitely non-compliant, but as an exercise
> > I thought I'd post it.  I don't actually plan on
> > implementing it, but it might generate discussion
> > about how JSTL 2.0 spec might handle this.
> >
> > From my understanding, <c:choose> & <x:choose> both do
> > not push out.write() to bodyContent. <c:set> on the
> > other does set out = bodycontent when needed. Example
> > from Jasper2 generated source below:
> >
> > javax.servlet.jsp.tagext.BodyContent _bc =
> > pageContext.pushBody();
> >           _bc.clear();
> >           out = _bc;
> >
> > Therefore if one were to modify <c:when> and <x:when>
> > to strip out extra line feeds, the output would have
> > to pushBody in order to call .trim() within the tag.
> >
> > There are several issues I can see with this method of
> > handling unwanted whitespace & control line feed.
> >
> > 1. doesn't solve the real problem
> > 2. it really should be addressed in JSP specification,
> > not JSTL specification
> > 3. it's better to not have dozens of extra
> > out.write("\r\n"); litering the compiled jsp class.
> > 4. There should be a way to easily plug in filters for
> > JSP page compilation. In the same way the latest
> > servlet spec defines request filters, page compilation
> > should have filters.
> > 5. leaving the extra out.write() makes pages with lots
> > of tag (100+) less scalable as seen with jasper1 on
> > tomcat 4.0.3 and 3.3.x.
> > 6. even though jasper2 now breaks tags without
> > scriplet code into it's own method, pages that use
> > both tag and scriplets will run into the 64K per
> > method limitation in java.
> >
> > Even though some servlet containers uses jasper, and
> > likely jasper2 once it is released, leaving in
> > unwanted whitespace and control line feed make tag
> > pages less portable across different servlet
> > containers. There's no gaurantee a server will compile
> > pages the way jasper2 does it.  Of course there is
> > always the option of writing a deployment tool that
> > parses the JSP to a temp directory stripping out
> > unwanted stuff and compile it to the server's working
> > directory.
> >
> > peter
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Sign up for SBC Yahoo! Dial - First Month Free
> > http://sbc.yahoo.com
> >
> > --
> > 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]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to