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