IFrame-Portlet with state?

[Kai Grossjohann <ka...@emptydomain.de>]

In the past, I thought that interactive iframe-portlets don't make
sense because the portal always loads the same URL into the iframe,
whenever the user clicks outside the iframe.

But preliminary experiments appear to show that it can sometimes work:
if the stuff inside the iframe is a web application which keeps the
session via cookies, then the cookie will be retransmitted to the
inside of the iframe on page reload.

So this appears to imply that the web app inside the iframe just needs
to have a URL which is sure to regenerate the current state based on
the HTTP session, and then Bob's my uncle.

Right?

Thoughts?  Comments?  Ideas?

Kai


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org

Re: IFrame-Portlet with state?

[Gerry Reno <gr...@yahoo.com>]

--- Kai Grossjohann <ka...@emptydomain.de> wrote:
> Gerry Reno <gr...@yahoo.com> 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?

Possibly.  Without knowing a lot of details it would be difficult to
offer an opinion on what you're trying to accomplish.  Should be easy
enough to try out little experiments and see what works for you.

> 
> What are the "other methods" that could be used to maintain state?

URL rewriting for instance.

> 
> > 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 ;-)

  The comments were in regard to how jetspeed specifically is handling
the control of its portlets.  Things like maximize, minimize,
print-friendly, etc.

Gerry Reno



> 
> Kai
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jetspeed-user-help@jakarta.apache.org
> 


=====
Gerry Reno
mailto: grenoml at@ yahoo dot. com
(if mail bounces please retry later - spam rapidly fills up mailbox)

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org

Re: IFrame-Portlet with state?

[Kai Grossjohann <ka...@emptydomain.de>]

Gerry Reno <gr...@yahoo.com> 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: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org

Re: IFrame-Portlet with state?

[Gerry Reno <gr...@yahoo.com>]

Kai,
  Within the iframe itself you could maintain a session as long as no
one reloaded the page that contained the iframe.  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 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.

Gerry Reno

--- Kai Grossjohann <ka...@emptydomain.de> wrote:
> Gerry Reno <gr...@yahoo.com> writes:
> 
> > And what do you do when people have cookies turned off as many do? 
> 
> I hang my head in shame.
> 
> I know that this is a problem.  But maybe companies' intranet
> applications can require a bit more from the web browsers than other
> websites.
> 
> If you write down what the user interface looks like that we have,
> then you get a pretty good list of things not to do in web
> applications.  But what can I do?  I try to argue as well as I can.
> 
> For example, the belief prevails that a web application can find out
> how wide in pixels is a certain string on the client: in the CSS file
> you specify that you want to use the foo font in the bar size, and
> then you can compute on the server side how wide is the string. 
> 'Nuff
> said.
> 
> > And how does a cookie help with an interactive remote logon session
> to
> > say a mainframe or to a multimedia presentation, etc., etc.
> 
> If the logon session is represented by an object in the HTTP session
> (in our case it is), and if you have access to the HTTP session, then
> Bob's your uncle.  No?
> 
> Kai
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jetspeed-user-help@jakarta.apache.org
> 


=====
Gerry Reno
mailto: grenoml at@ yahoo dot. com
(if mail bounces please retry later - spam rapidly fills up mailbox)

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org

Re: IFrame-Portlet with state?

[Kai Grossjohann <ka...@emptydomain.de>]

Gerry Reno <gr...@yahoo.com> writes:

> And what do you do when people have cookies turned off as many do? 

I hang my head in shame.

I know that this is a problem.  But maybe companies' intranet
applications can require a bit more from the web browsers than other
websites.

If you write down what the user interface looks like that we have,
then you get a pretty good list of things not to do in web
applications.  But what can I do?  I try to argue as well as I can.

For example, the belief prevails that a web application can find out
how wide in pixels is a certain string on the client: in the CSS file
you specify that you want to use the foo font in the bar size, and
then you can compute on the server side how wide is the string.  'Nuff
said.

> And how does a cookie help with an interactive remote logon session to
> say a mainframe or to a multimedia presentation, etc., etc.

If the logon session is represented by an object in the HTTP session
(in our case it is), and if you have access to the HTTP session, then
Bob's your uncle.  No?

Kai


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org

Re: IFrame-Portlet with state?

[Gerry Reno <gr...@yahoo.com>]

Kai,
  And what do you do when people have cookies turned off as many do? 
And how does a cookie help with an interactive remote logon session to
say a mainframe or to a multimedia presentation, etc., etc.

Gerry Reno

--- Kai Grossjohann <ka...@emptydomain.de> wrote:
> In the past, I thought that interactive iframe-portlets don't make
> sense because the portal always loads the same URL into the iframe,
> whenever the user clicks outside the iframe.
> 
> But preliminary experiments appear to show that it can sometimes
> work:
> if the stuff inside the iframe is a web application which keeps the
> session via cookies, then the cookie will be retransmitted to the
> inside of the iframe on page reload.
> 
> So this appears to imply that the web app inside the iframe just
> needs
> to have a URL which is sure to regenerate the current state based on
> the HTTP session, and then Bob's my uncle.
> 
> Right?
> 
> Thoughts?  Comments?  Ideas?
> 
> Kai
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jetspeed-user-help@jakarta.apache.org
> 


=====
Gerry Reno
mailto: grenoml at@ yahoo dot. com
(if mail bounces please retry later - spam rapidly fills up mailbox)

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org