>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
