Gerry Reno <[EMAIL PROTECTED]> writes: > Within the iframe itself you could maintain a session as long as no > one reloaded the page that contained the iframe.
Yes. > The problem we have now is mainly with the portlet control icons > causing page reloads that destroy the context of things like > iframes. Within a limited set of webapps, you can attempt to > maintain state through using cookies and other methods Well, like I said I was hoping the HTTP session should be enough. The webapp needs a single URL (servlet or JSP, or whatever) which is capable of looking at the session and gleaning the current application state from there. Then, said servlet or JSP (or whatever) should produce the right HTML. In fact, our webapp almost has this, but it invokes different URLs (each URL one frameset) for different states. So we just need to store the URL also in the session, and then make a JSP that dispatches to the different URLs, and then we're finished. Is this correct? What are the "other methods" that could be used to maintain state? > but overall it would be best if all of this portlet control stuff > were performed on the client and just a notification sent to the > server to inform it of what the current portlet state is. That way > there would not be any destruction of the state for things like > iframe portlets and you wouldn't lose your place in your portlet > ecommerce session, your mainframe remote logon session or your place > in your multimedia or video presentation. I'm afraid you lost me there. It seems you're saying it would be best for portlets not to be web-based. Heh, maybe you're right ;-) Kai --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
