Sandeep, The issue is that with servlet/JSP you can design your webpages to behave in a normal manner and only go to the server when you decide. You can use client-side DOM techniques to build a very responsive interface. With the portlet spec you are being forced into a server-side UI model with no choice. All UI interactions result in new page requests being sent to the server so the browser is constantly reloading pages over and over. A user with a dialup connection on a big portal site is going to find this very sluggish. If you have ever seen a well written DHTML interface you immediately notice how instanteously responsive it is. You can use JSP/servlets with these for obtaining server-side business data and for anything with regard to the presentation you just manipulate the DOM. So portlets could be as simple as <div> boxes that you can make move, shrink, expand, hide, all dynamically through the DOM. You can move <div> elements dynamically between layers and get many effects if you want. None of this is possible in any meaningful way under JSR-168.
Gerry Reno Sandeep wrote: > Gerry wrote: > where every view action, even simple view actions > like minimizing a portlet will go back to the server for a full page > reload. I believe that's the case with Jetspeed in its current form as well. Rather it is at \ the very core of the Servlet/JSP revolution. The model is clearly take a request in \ and return a response. Or maybe I am missing the point you are trying to make, Sandeep --- Gerry Reno <[EMAIL PROTECTED]> wrote: > The following are my comments to the JCP regarding JSR-168: > > --- Gerry Reno <[EMAIL PROTECTED]> wrote: > > Date: Thu, 17 Jul 2003 19:52:51 -0700 (PDT) > > From: Gerry Reno <[EMAIL PROTECTED]> > > Subject: JSR-168 Comments > > To: [EMAIL PROTECTED] > > CC: [EMAIL PROTECTED] > > > > I have recently reviewed JSR-168 and my overriding impression is > > that > > this specification is a non-starter in its current form. Promoting > a > > tightly server-coupled view interaction model (server-side UI) will > > end > > up hurting Java. The Web model (servers, browsers, and network) is > > not > > designed to work this way. Java is just now recovering from the > > early > > perception that it is slow technology. This is a perception that > > many > > of us have had to work hard to dispel. Now the JCP wants to > release > > a > > portlet specification on a foundation of a server-side UI model > that > > will end up tremendously fueling this argument. The user > experience > > using the portlets is going to be slow, awkward, and non-intuitive. > > > This specification with its server-side UI is going to do more > damage > > to Java than anything else. Try using one of these portals through > a > > dialup connection where every view action, even simple view actions > > like minimizing a portlet will go back to the server for a full > page > > reload. This is ridiculous! > > > > Please take a look at my proposal for a new Jetspeed View > > Interaction > > Model. The model in my proposal makes far more sense. > > > > > http://marc.theaimsgroup.com/?l=jetspeed-user&m=105846310309122&w=2 > > > > > --------------------------------------------------------------------- > > Proposal: Jetspeed View Interaction Model > > Author: Gerry Reno > > Date: July 17, 2003 > > > > Need: > > The Jetspeed portal needs to provide users with a good view > > interaction (browser) experience where portal pages and portlets > > behave > > in a fast, responsive and intuitive manner. Highly server-coupled > > view > > interaction models which require every user action to cause a new > > page > > request to be sent to the server result in slow, non-intuitive user > > interfaces that often exhibit undesirable side-effects and place > > unnecessary loads on networks and servers. What is needed is a > > minimally server-coupled view interaction model that permits all > > locally-achievable view modifications to be made on the client. > This > > results in minimal reloading of the document object model (DOM) and > > provides the user with a rich, responsive, and intuitive user > > experience. > > > > > > Demonstration of Highly Server-Coupled Problem: > > A good example of the type of problems that can occur under a > > highly > > server-coupled view interaction model can be found in Jetspeed > 1.4b4 > > using the IFramePortlet. This portlet implements the IFRAME tag on > > the > > portal page which has a 'src' attribute that contains a URL that is > > loaded in the frame whenever the tag is rendered during loading of > > the > > page. The IFRAME tag has no means of maintaining state and will > > always > > load the 'src' URL into the frame whenever it is rendered. This > > behavior is typical of HTML tag elements. Under the highly > > server-coupled view interaction model that is currently used in > > Jetspeed 1.4b4 this very useful IFramePortlet is rendered nearly > > useless by the fact that view actions on any portlet within the > > portal > > page cause new requests to be sent to the server which result in > page > > reloads that in turn result in the IFramePortlet being rerendered > and > > its 'src' attribute URL being reloaded. What this means is that if > a > > user is interacting with the IFramePortlet and clicking on links > > until > > they find a page of interest perhaps a shopping site with forms, > etc. > > > > and then they were to interact with any of the portlet view action > > buttons on any portlet within the portal page such as minimize or > > maximize, the entire page would reload and the users place within > the > > IFramePortlet would be lost since the IFRAME tag would be > rerendered > > and it would reload its 'src' URL. Try this for yourself to see > the > > problem. This is completely counter-intuitive to users general > > experience with IFRAMES. Under the minimally server-coupled view > > interaction model proposed herein the IFramePortlet would behave > > completely intuitively as users expect. > > > > > > Proposed Solution: > > Providing for a consistently good view interaction experience for > > users requires by definition, minimizing requests to the server and > > the > > use of rich client-side scripting in conjunction with keeping the > > same > > document object model (DOM) loaded in the browser for as long as > > possible. The DOM can be manipulated using client-side scripting > > languages such as DHTML and Javascript to accomplish local user > view > > actions. Actions that cause new page requests to be issued to the > > server should be kept to an absolute minimum to avoid unloading and > > reloading of the DOM. User actions that affect only the view such > as > > maximize, minimize, delete, print-friendly can then easily be > > implemented locally through manipulation of the DOM within the > > browser. > > In fact, all view interactions that can be locally-achieved by > > manipulation of the DOM should be done strictly on the client and > > never > > by a request to the server. Adopting this type of view interaction > > model results in a user interface that feels very crisp and > > responsive. > > While on a portal page, only when it is absolutely necessary to > > send/retrieve server-side business data should a new page request > be > > sent to the server such as when a form needs to be submitted, for > > example. > > > > > > Implementation: > > (I do not have familiarity with Jetspeed internal design or > source > > code and perhaps someone could provide some assistance here) > > > > > > Considerations: > > Internet Explorer broken CSS box-model: > > IE 5 has a broken CSS box-model which causes misalignment of > > things > > like sliced images when placed in <div> elements. There are ways > to > > directly detect broken CSS box-models (without relying only on > > user-agent strings which can be masqueraded) and apply corrective > > offsets to box parameters to compensate for this problem. > > > > Browser Usage Stats: > > source: http://www.doctor-html.com/agent_stats/ > > > > As you can see as of 7/05/2003 at least 95% are at a browser > > level > > of 5.x or higher. > > > > Cascading Style Sheets (CSS): > > All browsers worth supporting (5.x or higher) are capable of > > CSS1. > > > > > --------------------------------------------------------------------- > > > > > > > > Gerry Reno > > email: [EMAIL PROTECTED] > > > > > > __________________________________ > > Do you Yahoo!? > > SBC Yahoo! DSL - Now only $29.95 per month! > > http://sbc.yahoo.com > > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
