portals-jetspeed-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weaver, Scott" <Swea...@rippe.com>
Subject RE: JSR-168 Article Part 1 in JavaWorld
Date Thu, 07 Aug 2003 20:11:44 GMT
> 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   *
* weaver@apache.org                 *
*===================================*
  


> -----Original Message-----
> From: Gerry Reno [mailto:grenoml@yahoo.com]
> 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" <Sweaver@rippe.com> 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   *
> > * weaver@apache.org                 *
> > *===================================*
> >
> >
> >
> > > -----Original Message-----
> > > From: Gerry Reno [mailto:grenoml@yahoo.com]
> > > 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" <Sweaver@rippe.com> 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   *
> > > > * weaver@apache.org                 *
> > > > *===================================*
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Gerry Reno [mailto:grenoml@yahoo.com]
> > > > > 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" <Sweaver@rippe.com> 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   *
> > > > > > * weaver@apache.org                 *
> > > > > > *===================================*
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Gerry Reno [mailto:grenoml@yahoo.com]
> > > > > > > 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" <Sweaver@rippe.com> 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: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message