> 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. 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 > > this > > > > > > model > > > > > > > a single DOM with no IFRAME (ie true content aggregation), > > the > > > > > > hidden > > > > > > > iFrame being used as a backround content cache to be used > > by > > > > the > > > > > > main > > > > > > > window to load content. > > > > > > > > > > > > And act as the physical requestor back to the server. But > > yes, > > > > > > Raphael, this is exactly what I was getting at, using a > > single, > > > > > > hidden IFRAME, not an IFRAME for each portlet's content. > > > > > > > > > > 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. > > > > > > > > > > > > > > > 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] > > > > > > > > > > > > > __________________________________ > > > 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] > > > > > __________________________________ > 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]
