> 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 > > > 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] > > > > > __________________________________ > 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]
