Joachim, What on earth does accessibility guidelines have to do with types of scripting technology - this makes absolutely no sense. I can see restricting certain types of UI behaviors but not implementation technologies. Where may I find these german requirements.
Gerry Reno --- Joachim_Muller <[EMAIL PROTECTED]> wrote: > > Gerry > > we are currently working on a jetspeed project that has to > fulfill the accessibility guidelines as required by the > german goverment for all govermental website from 2005 on. > > One statement is to not be dependend on javascript for the > functionality of the website. > > If jetspeed pages would rely on DOM/Javascript this framework > would not be usable for govermental projects anymore, at least > in Germany. what a pitty, good for websphere though ;-). > > We are very happy that jetspeed does not rely on javascript > functionality. > > Joachim > > > > > -----Ursprungliche Nachricht----- > > Von: Gerry Reno [mailto:[EMAIL PROTECTED] > > Gesendet: Freitag, 18. Juli 2003 16:58 > > An: Jetspeed Users List > > Betreff: 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 > === 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]
