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]

Reply via email to