In the broader scope, what I think is necessary for both the portlet spec and for things like jsf is that anytime you are going to require maintaining the contexts for client-side technologies it is necessary that the main page not be reloaded and that the client interact with the server-side technology via a client-side controller/proxy talking to iframes which can be reloaded independently of each other and the main page. This lets you have the best of both worlds - enterprise-level server-side processing and rich, robust and fast client-side technologies.
rgds, Gerry Reno --- Gerry Reno <[EMAIL PROTECTED]> wrote: > Hi Scott, > > --- "Weaver, Scott" <[EMAIL PROTECTED]> wrote: > > Gerry, > > > > Here is how I envisioned it. You would have a "Request Proxy" > > probably a hidden IFrame that has the ability to write both to the > > client (DOM manipulation/screen repainting) and the server(record > the > > user's current page and portlet state/process non trivial portlet > > requests). > > > > This is over-simplified but gives you an idea of how I think it > could > > be implemented. > > > > The client-side portlet controller should exist in the main page > not > in it's own iframe. That would be destroyed anyway if the main page > were reloaded. The key is that the portlets have to exist in a > framework that allows them to be manipulated separately - the only > construct that is currently capable of this in a browser is the > iframe. > > 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]
