Hi Erik, You appear to be responding to the very beginning of the thread. You might want to read through the rest of the thread.
--- Erik Bruchez <[EMAIL PROTECTED]> wrote: > Gerry, > > You are starting a debate very similar to the one around JavaServer > Faces. Both JSRs strictly focus around a strictly server-side > framework as opposed to a client-side framework (or a combination of > both). > > To the defense of JSR-168, I think that client-side technologies are > at best flaky, a situation that hasn't changed much in 4-5 years > now. Microsoft hasn't made one significant improvement to IE since > version 4. They have made a number of improvements to support CSS. Agreed, they didn't implement the box model correctly in V5 but this is well known and easily compensated for. By client-side technologies I"m referring to Flash, SVG, applets, DHTML. These aren't at all flaky unless someone doesn't understand how to work with them. >Mozilla has done better, but represents an almost > insignificant market share. There is just not much happening in that > arena today, partly because of IE's monopoly. The question of chosing > a technology common denominator is difficult. > > The trend in the past few years has been to go back to server-side > technologies generating pretty basic HTML, JavaScript and CSS. Today, > the Web sites and Web apps with the best usability IMO are the ones > that try to minimize the use of fancy client-side technologies. In > theory diminishing the number of round-trips to the server is better, > but the reality is that round-trips work! Totally disagree - round trips make for a completely annoying user experience and it's what is wrong with many sites. It only works from the standpoint of being able to pick up server-side data. > > In addition, the JSR must allows for different types of clients, such > as PDAs. It also must be 100% agnostic wrt the technology used for > the > presentation (JSP, XSLT, etc.). Clearly not everybody has > standardized > on JSP. > > I think some of your concerns are valid (but not too important to > somebody like me I have to say) but remain way too theoretical. The > best approach to convince people would be to point to an > implementation addressing them. Such an proof of concept could be a > good basis for inclusion in a JSR. > > -Erik > Any proof-of-concept would have to come from those that are interally familiar with the implementation. Perhaps some Jetspeed team members might be willing to assist in producing such a proof. I really don't think it necessary. I think the arguments and points made in the thread speak for themselves. The current portlet spec completely destroys the capabilities of client-side technologies. In fact, some of the existing portlets do not even function properly due to the interaction model being dictated by the spec. If you read through all of the threads dealing with the issue you will find examples of all of these things. rgds, Gerry Reno __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
