> Ok, but I still think that an optional Refresh button makes sense in > some instances. Especially if you've set the TTL out very far and you > then decide you want to refresh the portlet without refreshing the > whole page.
Of course, and that would be up to the portlet developer to provide that sort of functionality within his/her portlets. Regards, *===================================* * Scott T Weaver * * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===================================* > -----Original Message----- > From: Gerry Reno [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 07, 2003 4:03 PM > To: Jetspeed Users List > Subject: RE: JSR-168 Article Part 1 in JavaWorld > > Hi Scott, > > --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > > > I don't see that as a problem. Rewriting the DOM itself is nearly > > > instantaneous from the perspective of the user. I see this > > happening > > > only for *volatile* portlets that much touch the server regularly. > > I > > > think that I would prefer though that such portlets have their own > > > Refresh button for obtaining updated content rather than always > > hitting > > > the server on every request. > > > > I don't like the idea of the onus being on the user "refresh" their > > portlets manually, seems a bit kludgy to me. I think if we reverse > > this, and make it so that portlets that have extensive TTLs, i.e. > > they rarely or never need periodic updates use the caching attribute > > within their descriptors to effectively skip their ender phases and > > portlets like the stock quote, update their content with each request > > by using the proxy to do so. > > > > Now, we are adhering entirely to the spec by using the functionality > > provided there in to effectively slow/stop the render phase for a > > portlet unless specifically requested by giving a very long cache > > period. > > Ok, but I still think that an optional Refresh button makes sense in > some instances. Especially if you've set the TTL out very far and you > then decide you want to refresh the portlet without refreshing the > whole page. > > > rgds, > Gerry Reno > > > > > > > > > Regards, > > *===================================* > > * Scott T Weaver * > > * Jakarta Jetspeed Portal Project * > > * [EMAIL PROTECTED] * > > *===================================* > > > > > > > > > -----Original Message----- > > > From: Gerry Reno [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, August 07, 2003 3:46 PM > > > To: Jetspeed Users List > > > Subject: RE: JSR-168 Article Part 1 in JavaWorld > > > > > > Hi Scott, > > > > > > --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > > > > The one thing we have to remember is that portlet content, i.e. > > stock > > > > quotes, weather, etc should be provided in real-time and as such, > > the > > > > content of these will need to be updated periodically. What I > > am > > > > getting at is that if the user only is changing window state we > > > > rarely get a chance to get back to the server to update all of > > the > > > > portlets' content on the page. I think this is the reasoning my > > > > statement below. > > > > > > > > We still need to observe the contract that every page request > > invokes > > > > each visible portlet's render method whether the request be a > > render > > > > request or an action request. > > > > > > The key word is *visible* portlet. > > > > > > The loophole in this is the fact that > > > > cached portlets' render method invocation can be skipped during > > the > > > > render/request phase. > > > > > > > > Look between lines 15 - 30 in the spec. > > > > > > > > Even with this requirement, the main page could still stay intact > > as > > > > all requests go through the proxy, however we may have to rewrite > > the > > > > DOM of multiple portlets due to the above issues. > > > > > > I don't see that as a problem. Rewriting the DOM itself is nearly > > > instantaneous from the perspective of the user. I see this > > happening > > > only for *volatile* portlets that much touch the server regularly. > > I > > > think that I would prefer though that such portlets have their own > > > Refresh button for obtaining updated content rather than always > > hitting > > > the server on every request. > > > > > > rgds, > > > Gerry > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > *===================================* > > > > * Scott T Weaver * > > > > * Jakarta Jetspeed Portal Project * > > > > * [EMAIL PROTECTED] * > > > > *===================================* > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Gerry Reno [mailto:[EMAIL PROTECTED] > > > > > Sent: Thursday, August 07, 2003 3:18 PM > > > > > To: Jetspeed Users List > > > > > Subject: Re: JSR-168 Article Part 1 in JavaWorld > > > > > > > > > > Hi Scott, > > > > > > > > > > Yes, this type of model shows some promise. Now, what is > > also > > > > > important to recognize is that by manipulating the DOM on a > > > > maximize, > > > > > that all the portlets are actually still present. Just not > > > > visible. > > > > > So perhaps we would need to send a message to non-visible > > portlets > > > > so > > > > > that they could perhaps 'pause' when they weren't visible. > > > > > > > > > > rgds, > > > > > Gerry Reno > > > > > > > > > > --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > > > > > > > Can you please clarify how this operates. Are you > > envisioning > > > > a > > > > > > proxy > > > > > > > requestor that will allow the main page DOM to remain > > intact. > > > > If > > > > > > so, > > > > > > > then this may work. If not, then it definitely would not > > work. > > > > > > > > > > > > Yes the main page stays intact and all portlet url's targets > > > > would be > > > > > > the IFRAME proxy. I have not put a lot of thought into the > > > > > > specifics, so that is open to discussion. Obviously, the > > proxy > > > > > > IFRAME will have to do A LOT of DOM manipulation in the main > > > > page. > > > > > > > > > > > > Here is a simple scenario: > > > > > > My apologies if the diagram gets out of whack ;) > > > > > > > > > > > > > > > > > > User click "Maximize" on a portlet > > > > > > | > > > > > > --> This request is sent to the proxy IFRAME > > > > > > | > > > > > > | > > > > > > (The proxy IFRAME then checks if DOM Manipulation required?) > > > > > > | | > > > > > > true false > > > > > > | | > > > > > > The DOM is re-written to Nothing is done to the DOM > > > > > > facilitate the new window | > > > > > > state. | > > > > > > | | > > > > > > | | > > > > > > ------------------------------------- > > > > > > | > > > > > > | > > > > > > The request is now sent back to the server > > > > > > to fulfill the JSR-168 requirements > > > > > > | > > > > > > Does the request response require a change > > > > > > In the target portlets content? > > > > > > | > > > > > > ------------------------------------- > > > > > > | | > > > > > > true false > > > > > > | | > > > > > > re-write the DOM Nothing is done to the DOM > > > > > > accordingly > > > > > > > > > > > > > > > > > > This is a very high level model of what I envision, it is by > > no > > > > means > > > > > > complete. > > > > > > > > > > > > *===================================* > > > > > > * Scott T Weaver * > > > > > > * Jakarta Jetspeed Portal Project * > > > > > > * [EMAIL PROTECTED] * > > > > > > *===================================* > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Gerry Reno [mailto:[EMAIL PROTECTED] > > > > > > > Sent: Thursday, August 07, 2003 1:02 PM > > > > > > > To: Jetspeed Users List > > > > > > > Subject: Re: JSR-168 Article Part 1 in JavaWorld > > > > > > > > > > > > > > Hi Scott, > > > > > > > > > > > > > > --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > > > > > > > > > Not exactly, the main user interface window would have > > in > > > === message truncated === > > > __________________________________ > 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]