The way I look at this for something like your graph example is that it is just as easy to generate this graph in the first request. Once in the browser the user then can then normalize, maximize the portlet as many times as they want without requiring any additional trips to the server. It is the server round-trips that are expensive and make for slow performance.
Gerry Reno --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > > The issue is where is it most efficient to perform certain > > functionality. I don't have any problem with concept of displaying > a > > graph next to the tabular data when the portlet is maximized. The > > problem I have is that this all should be done on the client. When > the > > portlet is maximized then the graph can be revealed. It shouldn't > > require an expensive trip to the server. > > I feel it's a waste to generate the graphs when nobody is actually > looking at them. That's just me though, I could just be brain dead. > > > > *===================================* > * Scott T Weaver * > * Jakarta Jetspeed Portal Project * > * [EMAIL PROTECTED] * > *===================================* > > > > > -----Original Message----- > > From: Gerry Reno [mailto:[EMAIL PROTECTED] > > Sent: Friday, July 18, 2003 10:58 AM > > To: Jetspeed Users List > > Subject: RE: Proposal: Jetspeed View Interaction Model > > > > Scott, > > The issue is where is it most efficient to perform certain > > functionality. I don't have any problem with concept of displaying > a > > graph next to the tabular data when the portlet is maximized. The > > problem I have is that this all should be done on the client. When > the > > portlet is maximized then the graph can be revealed. It shouldn't > > require an expensive trip to the server. > > > > Gerry > > > > > > --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > > > I think your proposal holds merit, however, it becomes too > > > restrictive in requiring that all portlets MUST use client > DOM/DHTML > > > to facilitate modifications to the portlet's window state. Like > I > > > said before, some portlets actually do things when maximized (and > yes > > > my users think it's very kewl to go from tabular data to tabular > data > > > and charts on maximize). > > > > > > I propose that if you want to start working on this, assign > > > javascript events to each portlet action. Then allow portlet > > > developers to right the javascript code that supports each event, > if > > > they want to. If they don't and are satisfied with the current > > > window state model, they don't have to do anything. The default > > > should remain as it is today, server-side processing of the > window > > > state. > > > > > > Start by looking at templates/vm/controls/html/essential.vm. > This is > > > the controller template that is used to render individual > portlets. > > > Javascript should be stored as CDATA in the portlet registry or > > > possibly link to an external script file. > > > > > > I do have some other requirements. The Javascript will need to > be > > > written in an object oriented manner as opposed to the every day > web > > > developers C-style procedural approach. I have already written > some > > > object oriented javascript libraries that deal with CSS-P > > > positioning, sizing and dynamic content writing and would be > willing > > > to donate it. > > > > > > > > > *===================================* > > > * Scott T Weaver * > > > * Jakarta Jetspeed Portal Project * > > > * [EMAIL PROTECTED] * > > > *===================================* > > > > > > > > > > > > > -----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 > === message truncated === __________________________________ 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]
