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.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
