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]
