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]
