To further illustrate the benefits of a minimally server-coupled view interaction model, consider a possible implemention of CMS authoring within Jetspeed: A good way to implement CMS authoring is via the use of an editor applet. Using a minimally server-coupled view approach this CMS editor applet could be implemented in a portlet. When the user wants to create/edit a site page they can use the applet in the portlet to author the page. If they want more screen real estate for their editing work, they can maximize the portlet while they are editing and restore it when they are finished all without affecting their CMS session. Now consider the alternative of the highly server-coupled view approach. The user begins using the applet editor in the CMS portlet, decides they need some more screen real estate for their editing so they maximize the portlet and at that point the portlet reloads to its initial state and they have completely lost their editing session. You can imagine many scenarios where similar non-intuitive behaviors will occur when using a highly server-coupled view interaction model.
Gerry Reno > > > > -----Original Message----- > > From: Gerry Reno [mailto:[EMAIL PROTECTED] > > Sent: Thursday, July 17, 2003 1:18 PM > > To: Jetspeed Users List > > Subject: Proposal: Jetspeed View Interaction Model > > > > > > 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. > > > > > ------------------------------------------------------------------------------------------------ > > > > > > > > __________________________________ > > 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] > > > > > > > --------------------------------------------------------------------- > > 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] > __________________________________ 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]
