Thanks for the useful comments. I do wonder, however, what JSP was
designed for unless for building dynamic web applications (aka server
pages), but I'll let that pass.
Based on this and other feedback, I've just added a "The Problem"
link in the left column that focuses on describing the problem and
less on attacks on particular solutions. Check it out; its at
http://virtualschool.edu/wap. Hot off the keyboard so there may still
be typos.
At 7:50 AM -0500 05/29/2001, Joseph Ottinger wrote:
>>Examine your JSP pages for where they generate links to other pages.
>>You'll find <a href="filename.jsp"> strings there which is precisely
>>my complaint. JSP treats pages the way html does, as filenames, not
>>objects, which automatically prevents compile time link checking from
>>working.
>
>I will? Ah, I see where you're going - but then again, JSP isn't geared to
>be what you're using it for. C'est la vie - and concedo, although I don't
>see it as that much of a flaw, as HTML pages are resources, but not
>necessarily objects.
>
>>Then look at where JSP deals with field request parameters. You'll
>>find that request->getParameter() returns Strings/nulls, which is the
>>point of my complaint that "Fields are not Strings". JSP provides no
>>tools for treating field parameters as application specific field
>>types. I explained why this was bad and how to fix it. Even provided
>>an AbstractField class that you're free to use if you want even
>>within JSP.
>
>Again, I don't have that much of a problem with this. I *do* see it as a
>slight limitation of the transport mechanism, because sending objects that
>aren't identifiable isn't an easy or clear thing when you only have 8 bits
>to work with (and yes, I know I'm ignoring UNICODE.)
>
>>You could of course use WAP (or a homebrew equivalent) within JSP,
>>which is exactly the path I followed before chucking JSP altogheter.
>>After all JSP contains Java inside. This is what how I lived with JSP
>>before I realized that it would be cleaner to just replace it
>>altogether.
>
>*nod* Although, again, I'm not convinced JSP is anywhere near as demonic as
>you're making it sound. WAP is trying to solve something different than
>typical JSP, so I'm still not sure the problem looms as large as you make it
>sound.
>
>>To head off another common misunderstanding, I explained in the
>>article why separating presentation and logic into separate FILES was
>>not a priority in my shop, and why moving html into separate METHODS
>>was sufficient separation for my needs. The article doen't explain
>>how to use MLS to read/parse HTML from files at runtime. This is only
>>because this wasn't a priority for my shop and so I never
>>investigated it well to write up instructions. I'll try to correct
>>this.
>
>*nod* Okay.
>
>>Regarding your last paragraph, the point of the article is that a web
>>application should be viewed as an object-oriented program that
>>happens to emit html text. The only limitations html imposes are on
>>web browsers. The fact that these limitations leaked into JSP
>>demonstrates my complaint about designing server languages as
>>extensions to browser languages as starting out on the wrong foot.
>
>But JSP wasn't designed as a generic "server language," regardless of the
>impression JSP-I may give you - and I think you know that. Nobody views JSP
>as a cure-all. (Again, ignore most of this mailing list when I say that.)
>Because JSP is generally targeted at what it's used for, you're not paying a
>huge price for its use outside fo the limitations imposed by the transport
>mechanism - and it certainly doesn't impose its restrictions on you. Want to
>do your own JSP-style content generation, via servlets? Do so! (Oh, wait -
>you did!) The "server language" here is the servlet API - and JSP is built
>on top of the servlet API to handle certain aspects of response generation.
>
>I'm not saying you have a BAD solution at all, nor am I saying I'm going to
>ignore it. I'll probably watch it and take what's useful to me out of it. :)
>
>Thanks! :)
>
>>At 6:11 AM -0500 05/27/2001, Joseph Ottinger wrote:
>>>Good thing you sent this on a holiday weekend. :)
>>>
>>>At any rate, I agree with the statement that Java should be used as Java,
>>>and not deficient Perl - but I *do* take slight issue that JSP encourages
>>>the latter behavior. To a degree it does, sure - but nobody with
>>>experience
>>>in Java thinks that JSP is more than a convenient mechanism for rendering
>>>data (along with some capability for generating it.) Those who don't think
>>>that... well, even they can get things done, a testament to the relative
>>>genericity of JSP.
>>>
>>>As far as broad adoption... post to usenet, post to slashdot, post to
>>>javalobby, post to freshmeat, post to the mailing lists. Good luck
>>>replacing
>>>JSP in J2EE... and I disagree with your statement that JSP encourages the
>>>view of data as anything other than what it is. Sounds like an axe is
>>>being
>>>ground ("I invented somethin'! Come lookie here!") and I'd be interested
>>>in
>>>how you arrived at the conclusion, because the only limitation JSP has in
>>>this area is forced upon it by the rendering engine.
>>>
>>>>From: Brad Cox <[EMAIL PROTECTED]>
>>>>Reply-To: A mailing list about Java Server Pages specification and
>>>>reference <[EMAIL PROTECTED]>
>>>>To: [EMAIL PROTECTED]
>>>>Subject: Just say no to JSP
>>>>Date: Sat, 26 May 2001 17:04:49 -0400
>>>>
>>>>I've just completed a major revision of the WAP software and
>>>>articles that were published in the last two month's Dr. Dobb's
>>>>Journal.
>>>>
>>>>The software and articles are available at
>>>>http://virtualschool.edu/wap. The demonstration application isn't
>>>>working there yet (tomcat configuration still underway).
>>>>
>>>>Please check it out. I welcome all comments, particularly suggestions
>>>>as to how to get this approach broadly adopted.
>>>>
>>>>Just say no to JSP
>>>>
>>>>Perl and JSP encourage the view that web pages are files, links are
>>>>file names, and request and database fields are strings. But although
>>>>html does represent everything as data, html is a restriction on
>>>>browsers, not web applications.
>>>>
>>>>Java should be used as a fully object-oriented language, not as a
>>>>deficient Perl. Pages should be page objects, links between pages
>>>>should be messages between objects, and fields should be instances of
>>>>application-specific fields that encapsulate the ability to validate
>>>>user input.
>>>>
>>>>WAP was developed and tested with the Apache/Tomcat/JServ servlet
>>>>engine but should work with others such as Resin. If the engine
>>>>supports JSP it is not used. The software replaces the sole useful
>>>>feature JSP provides with the MLS preprocessor described below.
>>>>--
>>>>---
>>>>For industrial age goods there were checks and credit cards.
>>>>For everything else there is mybank.dom at
>>>>http://virtualschool.edu/mybank
>>>>Brad Cox, PhD; [EMAIL PROTECTED] 703 361 4751
>>>>
>>>>===========================================================================
>>>>To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
>>>>JSP-INTEREST".
>>>>For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST
>>>>DIGEST".
>>>>Some relevant FAQs on JSP/Servlets can be found at:
>>>>
>>>>http://java.sun.com/products/jsp/faq.html
>>>>http://www.esperanto.org.nz/jsp/jspfaq.html
>>>>http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
>>>>http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>>>
>>>_________________________________________________________________
>>>Get your FREE download of MSN Explorer at http://explorer.msn.com
>>>
>>>===========================================================================
>>>To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
>>>JSP-INTEREST".
>>>For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST
>>>DIGEST".
>>>Some relevant FAQs on JSP/Servlets can be found at:
>>>
>>>http://java.sun.com/products/jsp/faq.html
>>>http://www.esperanto.org.nz/jsp/jspfaq.html
>>>http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
>>>http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>>
>>
>>--
>>---
>>For industrial age goods there were checks and credit cards.
>>For everything else there is mybank.dom at http://virtualschool.edu/mybank
>>Brad Cox, PhD; [EMAIL PROTECTED] 703 361 4751
>>
>>===========================================================================
>>To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
>>JSP-INTEREST".
>>For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST
>>DIGEST".
>>Some relevant FAQs on JSP/Servlets can be found at:
>>
>>http://java.sun.com/products/jsp/faq.html
>>http://www.esperanto.org.nz/jsp/jspfaq.html
>>http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
>>http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>===========================================================================
>To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
>JSP-INTEREST".
>For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
>Some relevant FAQs on JSP/Servlets can be found at:
>
>http://java.sun.com/products/jsp/faq.html
>http://www.esperanto.org.nz/jsp/jspfaq.html
>http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
>http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
--
---
For industrial age goods there were checks and credit cards.
For everything else there is mybank.dom at http://virtualschool.edu/mybank
Brad Cox, PhD; [EMAIL PROTECTED] 703 361 4751
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
