Sandeep, I don't understand your argument. This isn't about client-side apps.
Gerry Reno --- Sandeep Dixit <[EMAIL PROTECTED]> wrote: > With client apps, you are trading-off ease of maintenance for better > performance. Imagine maitaining your client application on 100,000 > machines or even for that matter 100 machines. > > Sandeep > > ---------- > From: Gerry Reno > Sent: Friday, July 18, 2003 11:19 AM > To: Jetspeed Users List > Subject: RE: Proposal: Jetspeed View Interaction Model > > 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] * > > > > f 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] > === message truncated ===> --------------------------------------------------------------------- > 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]
