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]
