If we used client-side operations to alter window state, how would we maintain/persist a user's window state when that user closes their browser?
What if a user logs in from a different browser on a different machine, wouldn't they expect the state of there portlets to be same no matter where they are accessing the portal from? *===================================* * Scott T Weaver * * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===================================* > -----Original Message----- > From: Gerry Reno [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 06, 2003 11:58 AM > To: Jetspeed Users List > Subject: Re: JSR-168 Article Part 1 in JavaWorld > > -trying to tie this linkage back to the original thread - > > >De : Gerry Reno [mailto:[EMAIL PROTECTED] > >> > >> Hi Raphael, > >> > >> --- "Luta, Raphael (VUN)" <[EMAIL PROTECTED]> wrote: > >> > > >> > If I understand correctly your request in regards to the > >> > JSR 168, you would like to be able to develop a client based > portal > >> > that leverages the portlet components developped against the > JSR168 > >> > API. Is that correct ? > >> > > >> > I think that what you can do in this case is implementing > >> > a portal "server" on the client, with client side technologies > that > >> > interact with a remote portlet container over the network, > >> for example > >> > through WSRP. In such a setup, your client can control exactly the > >> > aggregation behavior and still leverage any JSR 168 portlets > through > >> > WSRP. > >> > > >> > Since JSR 168 assumes a server-based aggregation process, > >> it can not > >> > answer alone your requirement but OTOH I don't think it's a > >> > showstopper since WSRP will perfectly handle this requirement. > >> > > >> > Am I missing something here ? > >> > > >> > >> Are you suggesting that in order to accomodate client-side > >> technologies that a browser plugin 'portal server' would be > >> necessary? > >> Users would reject this outright. I really don't see how > >> this would solve the problem. It is the whole interaction > >> model that is the problem, not where the 'portal server' lives. > >> > > >No, I don't think you need a plug-in, you just need to write > >in Javascript the code that will actually aggregate the content on > >the client instead of aggergating on the server. > >In such a model, you're really back to standard client/server model > >where most of the intelligence is on the client. Such a process flow > >could be: > > >clients open up 2 frames/iframes/windows (1 of which is hidden from > the > >user with a 0 size or whatever trick you fancy): > > >1st frame loads from HTTP server the JS/applet code that will be the > >portal server and starts displaying the portal page > >The JS code fetches the PSML (or equivalent) information from the > >portal server and loads it into the second frame, then it parses the > >XML information through DOM and activates remote portlet through > >WSRP as needed. > >If you need to save information to a remote server (liek storing user > >preferences), you can do it either through HTTP POST or directly with > >a SOAP request. > > All I see this doing is moving around the portal server and playing > tricks with the markup. I think we would need to see some type of an > example to examine whether this offered any possibilities. > > 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]
