Discussions

News: Just say no to JSP: Web Applications as Servlets

Bookmark and Share Get thread feed

  1. Just say no to JSP: Web Applications as Servlets (17 messages)

    The conventional approach to building web-based applications involves writing the UI in HTML-based languages JSP or ASP. A different approach is described in the lastest online issue of Doctor Dobbs - one that exploits Java's type-checking ability to validate field parameters and detect invalid links between pages. How do you think they compare?

    Read Web Applications as Java Servlets.
    Story Source: Application-Servers.com.
    Reply to this

    Threaded Messages (17)

  2. Just say no to JSP: Web Applications as Servlets[ Go to top ]

    I think that the MVC model has been addressed many times
    by many writers. I could not see any innovation on this particular approach. It is confusing and it only ties the design and development process even more. My main problem when programming a site is that the pages are always changing even after the application is deployed, I cannot compile and restart the server every time a designer or content creator changes something.

    As a matter of fact, the writer stresses the uniline limitation of the Java Language ... can't one use the usual "\n" to overcome such "limitation"? Am I missing something?

    By the way, can someone refresh my memory with the Java String length limit?

    Christian Rauh
    Reply to this Reply to original

  3. Just say no to JSP: Web Applications as Servlets[ Go to top ]

    I agree with Christian. Applying MVC to Web-application design (including checking parameter validy by encapsulating parameters in value classes) isn't new. Old versions of Sun's J2EE Blueprints (even back when it was called the APM) had described this technique.
    Further, IMHO the use of MVC in this specific article is an anti-pattern. One of the greatest drives for MVC is that it seperates view rendering logic from application logic. Hence, you can reuse views, and you can put different views on top of an existing application. In Web apps, this is twice as important. You have completely different people for rendering the views (usually Web design experts) and for coding application logic (programmers).
    What happens in this implementation, is that there is no such seperation. View classes also manage application logic using their "control" method. IMHO, while this is a legitimate design, it can't be called "MVC". You cannot easily reuse either the application logic or the rendering logic.

    I also didn't see any reason in the article why JSPs can't be used. All the great type checking, semantic validity checking, link checking, blah, blah, blah can be performed in Model and Controller classes while rendering views is performed by JSPs. This is actually the technique described in the Blueprints, for instance. I had used this technique without any problem, and I didn't see anything in the article that convinced me I should drop the reusabillity and clear seperation between teams that it has given me.

    If anybody else has different views/expiriences on this I would love to hear them :)

    Gal.
    Reply to this Reply to original

  4. Just say no to JSP: Web Applications as Servlets[ Go to top ]

    There always seems to be a huge push to replace JSP with ... something. It depends on the solution that a given person is pushing.

    I've yet to run into a solid argument to support this; even Jason Hunter's viewpoint has largely failed to convince me. Anyone want to offer up another set of reasons?
    Reply to this Reply to original

  5. Just say no to JSP: Web Applications as Servlets and XLS[ Go to top ]

    I say no to JSP but not for the same reason than in the article.
    What about XML ? why don't create some XSL pages rather than JSP.
    If you have an appropriate XSL editor you can keep the separation between the look&feel and the business tier.

    The main advantage is that it is much more easier to modify. If something changes in your business tier, with the classic approach (JSP or ASP) you need re-compile you JSP. With the second approach (XSL), you just need to test.

    Vincent
    Reply to this Reply to original

  6. Just say no to JSP: Web Applications as Servlets and XLS[ Go to top ]

    I've concidered Vincen'ts approach in two prjects I recently participated in. We ruled it down because of two primary problems:
    1. Not enogth web designers knew XSLT or XSL, and support for them in authoring tools wasn't good enogth.
    2. Performing general-purpose transformation is, and allways will be, slower. It's certainly much slower than using a compiled solution like JSP. Our tests showed 1-3 to JSP even when the stylesheets were extremely basic. Moving transformations to the client causes all sorts of problems I don't want to get in right now.

    I suppose in a year we will have:
    1. more people with XSL knowledge, more XSL tools.
    2. Better performance XSL proccessors, maybe even pre-compiling ones (I saw one already, but it didn't meet our requirements).

    IMHO, after that happens, XSL will indeed be a strong tool that could sometimes be used where JSPs are used more efficiently.

    BTW: I don't see your point about recompiling JSP pages. As far as the developper is concerned, he just edits the JSP pages. The server recompiles them behind the scenes, and it requires no extra work on the developer's side.

    Gal
    Reply to this Reply to original

  7. Just say no to JSP: Web Applications as Servlets and XLS[ Go to top ]

    XSL is very slow right now, but people are working on this -
    eg Xalan have in development currently an XSL compiler which works the same way the tomcat JSP compile does (instead of pre-interpreting XSL as it does now)

    However the beef I have with a lot of these solutions is that while they may split content and presentation, _where_ they split dictates the tools your designers must use, and more often than not it dictates tools they don't. JSP development in an MVC model is still a pain because you end up having to merge changes to _html_ produced by designers with the tags you are using, because by and large it is straight HTML editors like DreamWeaver they'll be playing with.

    A 'good' answer to this is Enydra's XMLC, which lets the designers just use straight HTML. However you can copy the XMLC meme and use XSL to merge in your JSP/XSP/ASP/XSL code with source HTML, so the designers can write in the language they like, and the developers can write in the language _they_ like - ie whatever you think is fast enough for run time.
    Reply to this Reply to original

  8. Just say no to JSP: Web Applications as Servlets and XLS[ Go to top ]

    I completely agree with your views . Cos I am a close follower of XML and its associated components. it works very well. But this particular concept is good for a R&D sombody can try it out how suitable it is for a large and midium sites.
    Raghuram
    Reply to this Reply to original

  9. Just say no to JSP: Web Applications as Servlets and XLS[ Go to top ]

    I started using servlets when they first came out - no JSP, no J2EE etc, so I had to build a solid system myself, and I think it works well. Would be interested to know what others think of this template system.

    Each servlet is associated with one or more "include files". These include files are stored on the server, loaded into a Hashtable (filename as key) the first time they are requested, and each additional request simply reads the file from the hashtable (alternatively, the hashtable also stores the time the file was last modified, and when there's a request a check is made to see if the file has changed, if it has the latest version is read into memory).

    Typically, the servlet will firstly read in a template file (this is html common to all servlets), and then an include file which is particular to the request being made.

    Each file contains lots of variables enclosed in tags, I use <%= variablename %>. The servlet creates a hashtable of variables, parses the file for the <%= tags, and replaces the variable with the value in the hashtable.

    To me, this is a very, very simple way of doing it. The overhead is less than 1 millisecond even for files over 1mb in length with loads of variables.

    The design is kept separate to the logic, you can edit html without recompiling jsp, it's fast (the JVM would die before the parsing becomes an overhead to worry about), and it's memory friendly too.

    As far as the database goes, I just use the DBConnectionBroker from javaexchange.com and it does a fine job. Also have a static Databases class for loads of utitilities for frequently used code.

    any comments? I would be interested to know your thoughts -

    webmaster at kirkyonline dot com

    cheers

    dan


     
    Reply to this Reply to original

  10. Just say no to JSP: Web Applications as Servlets and XLS[ Go to top ]

    Seems like a nice approach. But what about the Performance of the Parsing? ...
    Reply to this Reply to original

  11. Just say no to JSP: Web Applications as Servlets and XLS[ Go to top ]

    what can be the best substutite for servlets and how can we execute them
    kindly help me.
    Reply to this Reply to original

  12. Just say no to JSP: Web Applications as Servlets[ Go to top ]

    Christian... What uni-line limit? you can use \r\n inside a string, though the system property "line.separator" is better. There are no limits on string lengths... the limit is your memory.

    As for JSP's, I believe the only major benefits I've seen have been:
    1) Autodumping of request parameters into a Javabean
    2) Custom scoped JavaBeans
    3) Tag libraries.

    As for the MVC architecture, I really would suggest people should look at WebObjects, http://www.apple.com/webobjects for perhaps the most advanced approach to MVC style database-driven web development today. J2EE is approaching WebObjects' level, but not quite yet.
    Reply to this Reply to original

  13. Just say no to JSP: Web Applications as Servlets[ Go to top ]

    If your familiar with WebObjects then Tapestry will look familiar. It's founded on the same ideas, but works better in a Java / J2EE world --- and it's open source.
    Reply to this Reply to original

  14. Just say no to JSP: Web Applications as Servlets[ Go to top ]

    I'll offer another MVC framework designed around being able to use XSLT as a templating engine: Maverick. It can wrap a JavaBeans model with a DOM facade, eliminating the need for JSP or XSP or some other intermediate templating system to generate XML. This should go a long ways towards improving the performance and usability of XSLT in web applications.

    Jeff
    Reply to this Reply to original

  15. Just say no to JSP: Web Applications as Servlets[ Go to top ]

    I think he's dead on that JSPs are not a good solution. In last June's JavaReport, I presented some ideas I've used to "tame" JSPs using MVP. However, my current efforts replace JSPs with Tapestry.
    Reply to this Reply to original

  16. server push[ Go to top ]

    hi,
    i just want to push web pages from server
    to client after client sending the request
    for the push.
    can u pl tell me how to refresh the client
    screen for every single web page push
    thank u
    praveen
    Reply to this Reply to original

  17. server push[ Go to top ]

    You can use pushlet, a framework. vist http://www.justobjects.nl/pushlet/
    Reply to this Reply to original

  18. Jsp does have advantage[ Go to top ]

    In my project, we cannot do without JSPs. some UI logic has to be written with this technology.
    To decouple with the biz tier, we use xml as a communication protocal. The developers are grouped as jsp developer and backend developer. They program seperately and test seperately. Everything is ok.
    Reply to this Reply to original