Hi David, > 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. >
--- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > 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. This is what I am talking about when I refer to client-side technologies being severely restricted. Any client-side technologies are going to be limited by the fact that they will live only until the next button press on the portal and then they will be destroyed and recreated with the next page load. For client-side technologies it's as a famous catcher once said, "It's deja-vu all over again". As far as the maximize example, if you remember from some of my other threads that what is expensive is server round-trips. My preference would be to see that all the content, both normalized and maximized markup is sent to the browser in the initial request and then window state changes only cause that content to be revealed or hidden as appropriate. The content for the normal display can be sent with the additional content for maximized view being loaded in the background so that there is no delay in the presentation of the portal page to the user. As far as print-friendly, you just go from a CSS attribute of 'media=screen' to 'media=print'. You can just manipulate the DOM to cause this to happen! You don't need to go to the server. > > 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. The time to address these issues is now, not later. The basic model for portable portlets is being established right now. It isn't going to be possible to 'extend' this model later to accomodate the type of interaction that I'm proposing. The fundamental model needs to be established correctly, right now, in order to be able to extend it later. The reason that you are steering clear of good client-side technologies such as applets is because the current spec prevents you from using them in any meaningful way. > > 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. With the way in which the portlets operate currently, I'm finding myself driven towards doing everything inside IFrames with a reload button on them in order to be able to utilize anything with regard to client-side technologies. This has been my same experience with jsf. I find myself only using jsf inside of an iframe so as to be able to maintain the context of the main page and not have everything constantly reloading and destroying the client-side technology contexts. > > 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 > It is definitely applicable to the portlet spec which is dictating a rigid user interaction model that is server-only centric. And I think one that is ultimately going to be rejected by users once they gain experience with using it. 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]
