All of us are using JSP for a long time for presenting dynamic content on the web. Actually when we use the JSP in MVC paradigm, we have a little of work performed by the JSP. All of the control DB Access and the other services are given by the Bean & servlets. My Question is Why cant we use some client side objects reteriving and displaying the values passed from the servlet?. That i think will reduce the processing time required by the server for compiling and loafing JSP page. Precisly whart i mean is servlets & beans are on the serverside and client side simply has pages with objects capable of retrieving & displaying the content from the server (typically implemented using scripts / other light weight technologise) I am not against the JSp technology as it has some other powerful features but what i want to say is, If we want only to present the values stored in the bean, what is the need for constructing huge JSPs -
hi suresh, interesting topic.. lemme copy one line from ur message My Question is Why cant we use some client side objects reteriving and displaying the values passed from the servlet?. cld u tell me more about that client side object (if it exists)... thanks raj...
SCJP, SCWCD, SCBCD, Oracle Certified Professional (SQL n PL/SQL)
Joined: Sep 07, 2002
By client side objects what i mean is the bean like objects executed by the JVM in the browser which are capable of mapping the values from the servlet (similar it activeX components ). these should be executed by the browser and only for getting/mapping data and displaying so they cant communicate directly to the server & no security breach. Why i posted this topic is that for simpla cases, we can use this approach to reduce the response time but i dont have any implementation ideas & leave it for discussion to this forum. Hope someone could find a good solution for this
Hi, objects executed by the JVM in the browser This is misleading... How do u expect JVM to be run in browser? JSP's main intetion is to separate concerns of page designers and programer's (resposbile for businees logic)concerns and easy maintainene thereby.. In ur q , u told that JSP is not doing any function like DB access..Infact, JSP can do but having this in JSP is not good pracice.. By mving this to custom Tags/Servlets programmers can concentrate on task in hand..that is implementing business logic..and page designers can concetrate what they can do best .. oi.e page designing.. After one year into production..U want to change table header color in ur page..No issues..could be done by page designer alone without changing any .java files..
Originally posted by rgsuresh: client side simply has pages with objects capable of retrieving & displaying the content from the server (typically implemented using scripts / other light weight technologise)
So what you're suggesting is that the client fetches some XML document containing the data without rendering directions, correct? This approach has existed for a long time by now (does "fat client" ring a bell?). However, this requires the client software to have certain capabilities. It has to understand how to render the user interface based on your XML schema. On the other hand, if the XML you are passing does contain rendering information, you are better of with a standard such as HTML/XHTML, which is much easier to generate using JSP than a servlet with tons of out.println's (and of course better supported by existing software)... [ April 23, 2003: Message edited by: Lasse Koskela ]
Hi All I accept the suggestion of Lasse Koskela abt tthe client becoming fat. But Whhat I am talking is about the Java runtime support which must be present on the client side if we want to run any java related things. So the design must be centered around the Java support on the client. So I think the client wouldnt become fat. I suggest this design only for very simple web apps & not for highly dynamic portals.
"sureshg" We have a naming convention for user display names in the hope that in sufficiently dim light we'll be mistaken for professionals. You can read about it here. J2EE is mostly about server-side processing. While it would be great to offload more things to the client, there's a couple of reasons why we try not to: 1. A certain large software company located in the Nothwestern U.S. has been so petty as to release products with buggy, nonstandard, insecure, and more recently, missing JVMs. So you can't count on the client having one. 2. A lot of times the bandwidth required to get all that data to and from the client would make the client-side experience unpleasant. 3. The standard applet sandbox as well as every firewall between client and server can limit types of ways that the client and server can trade information. The only way you can count on is HTTP to the same server that the client applet loaded from, and HTTP isn't capable of asynchronous communication. 4. Last, but not least, there are certain people out there who would find it amusing to take the data you sent to the client and replace it with data of their own devising in the hopes of doing things you didn't want them to do. It's never wise to trust the client side with anything that will hurt anyone except themselves.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Sep 07, 2002
mmmm...so now this discussion has turned AJAX ! :thumb: