> I'm assuming that there would be an 'API' so that the developer would
> know how to talk to the proxy and request their portlet refresh.

Developers should not need to be aware of this.  We would have configuration options 
that would generate URLs that would be aware of this and possibly use javascript to 
intercept these requests and send them to the proxy.  Like I said I don't have all the 
technical details figured out. 

We need to hide as much of the implementation as possible from the developer so their 
portlets can be used in portals that support JSR-168 but do not support the extended 
DOM interaction model you are proposing.


Regards,
*===================================*
* Scott T Weaver                    *
* Jakarta Jetspeed Portal Project   *
* [EMAIL PROTECTED] *
*===================================*
  


> -----Original Message-----
> From: Gerry Reno [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 07, 2003 4:11 PM
> To: Jetspeed Users List
> Subject: RE: JSR-168 Article Part 1 in JavaWorld
> 
> Hi Scott,
> 
> --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote:
> > > 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.
> >
> 
> I'm assuming that there would be an 'API' so that the developer would
> know how to talk to the proxy and request their portlet refresh.
> 
> 
> rgds,
> Gerry Reno
> 
> <snip/>
> 
> __________________________________
> 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]

Reply via email to