> 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]