Erik, Serge (I'm going to respond to both of you here) --- Serge Huber2 <[EMAIL PROTECTED]> wrote: > At 14:44 06.08.2003 -0700, you wrote: > > The portlet spec is locking out client-side technologies!! If > the > >arguments and points that I have presented have not convinced you > then > >sobeit. I can pretty much guarantee you that going forward with the > >spec the way it is it will fail. Users are going to reject the slow > >performance the lack of being able to use good client-side > technologies > >that other portal implementations are going to allow. The only way > >that I'll even consider designing anything around this current spec > is > >to remove all of the portlet window state buttons and portlet mode > >buttons so that I can use some client-side technologies in the > portal > >and the user won't be experiencing constant page reloading. > > Well the spec is actually very close to the Servlet API in some ways. > The > Servlet API is also quite minimal in it's coverage, and I wouldn't > call it > a failure despite the fact that it didn't cover areas such as : > > - browser capabilities > - client-side supported technologies > - file uploads > > etc... > > I do understand very well the point you are making. For example I > personally prefer to use an email client such as Evolution or Eudora > than > using the web interface of Hotmail or Yahoo Mail. Why ? Because of > all the > server round trips that do make some operations tedious. But I also > like to > have my mail all in one place, and not have to login into seperate > web > interfaces to check my mail, which I guess brings my needs back to > portal > needs. > > But I fail to understand your point as to why the current spec is > locking > client-side technologies out. As I said previously I think the spec > is > lacking in the areas of specifying the lookup and dispatching > technologies > to portlets, but I think that can come in a later revision of the > spec, or > become a defacto standard through the promotion of technologies such > as > Pluto that are (will be actually) under a very free license such as > Apache. > I think the spec doesn't include client technology support as per > say, but > I wouldn't say it "locks it out". > > If I take a quick look at what is needed using todays technologies in > order > to make the client-side experience nicer : > - Javascript > - DOM Level 2 > - Probably LiveConnect if we want to interact with applets > - A way to communicate on a portlet basis with the server, be it > iFrame, or > SOAP calls or something like that. > On the server-side we need : > - a SOAP server or an HTTP server that hooks up to the client > - A collection of portlets > > Now what let's say that the portlets interact with the client through > WSRP. > Why couldn't the WSRP server communicate with it's portlets through > the > JSR-168 interfaces (which is exactly what Oracle's implementation > does btw) > ? It would then just be up to the implementation of the portlets to > follow > guidelines (which are NOT in the spec), to interface well with the > client > side controls. These guidelines might be what you think is lacking in > the > spec, but as I see it it is technologically possible to do this, > although > not as easy. > > The point I am mostly trying to make here is that the spec is aimed > at > defining how portlet developers should do their work in a broad and > all-encompassing fashion. Constraining them too much will probably > scare > them away. Now they should ALSO have the possibility to write code > without > any client-side controls, and the spec allows this too. But I think > that if > there is some serious flaw in the spec that we have yet to uncover, > either > we must correct it now if still possible, or it will be corrected in > a > later update. > > Regards, > Serge Huber. >
I think that this spec needs to recognize that in order for a portal to be able to preserve the context for client-side technologies, which by definition means that you must maintain the integrity of the main page DOM, that it cannot have every portlet action reloading the main page. Now it can have portlet actions reloading iframes. But if the actions are going to reload the main page then there is no way to preserve the context for the client-side technologies and therefore the client-side technologies have been rendered virtually useless. I see no way that WSRP or anything else will improve this unless of course you talking about hacking whole tree sections of the DOM instead of reloading the whole main page. The model that is necessary to insure that client-side technologies are usable would involve having the portlets all implemented as iframes with a client-side controller/proxy to talk to the server and to control the presentation of the portlets in the browser itself. This does not mean that you are prevented from having portlets operate in a mode without client-side control. The key is specifying the right model that will permit the case for also allowing a client-side controller that can be used to talk with the portlets (all iframe based) and will permit the main page to remain intact in the browser so that client-side technologies will be able to maintain context and work all the while portlets are changing window states or portlet modes. 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]
