On Tuesday, August 5, 2003, at 06:47 PM, Gerry Reno wrote:
From my perspective this is very important since JSR-168 is going to be declared *the* standard. The standard should provide enough flexibility to accomodate all the common types of paradigms and technologies to which users have come to use when utilizing the Web. The portlet spec as currently written is analogous to having a number of browsers open on your desktop and each one would represent a portlet and if you were to hit the reload button or minimize or maximize or submit a form from any of them, then all of them would reload their pages. Well this works great if you don't mind losing any client-side processing that is going on. The problem is that users are accustomed to having client-side processing and in fact expect a consistent context when interacting with client-side technologies. As it stands now, the portlet spec is dictating that every portlet mode or window state change causes an action request to be sent to the server. If you understand how the browser and pages and the document object model and browser client-side technologies work you immediately realize that constantly reloading pages is not a good thing.
With the portlet api, you are free to handle client-side programming, inside the scripts and content generated by your portlet.
However portal-level events such as minimize and maximize, or a portlet action, must be passed back to the portal so that the
targeted portlet is notified of the event. Portlets, like servlets, are server-side objects and that is what the Java specification focuses on.
Im thinking about your maximize example. Wouldn't most cases require different or more content in maximized mode, requiring a trip back to the server?
Same for print friendly mode.
Your point about reloading and losing state of the other portlets is well taken.
Even IFrame portlets require state management and rewriting.
I try to steer clear of applets when working with portlets.
I do think these issues need to be addressed in future versions of the spec.
You also spoke about when a form is submitted from within an IFrame.
In Jetspeed today, we are capable of returning only the content of the particular portlet back to the IFrame.
The Portlet API is restrictive here, requiring that all portlets return content per request
Jetspeed could add an extended mode to support this, but then your portlet may not be portable.
I'd like to say that in general I agree with what you are saying regarding the user experience problems with portlets and constantly reloading everything.
Im still trying to figure out if its really applicable to a Java Portlet specification.
My gut feeling is that it should be, Im just not sure how yet.
-- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] +01 707 773-4646
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
