Remember frame sizes for web application across reloads and frameset changes?

[Kai Grossjohann]

I have a web app which comprises different frames: a menu bar frame, a
search form frame, a result list frame. Depending on the state, only
a subset of these frames is available. (Eg, after login, only the
menu bar frame exists to allow the user to select a search form.
After this, only the menu bar and the search form are visible.)

Now the users are to be able to resize the frames.

WIBNI the webapp could remember the frame sizes across reloads and
frameset changes? For example, if the user resizes the menu bar frame
after login, then it should retain the width even after the user
chooses a search form, and after performing the search.

I have been able to remember the frame width in a cookie by using
JavaScript and onunload events. I have also been able to frob the
frameset definition on load, to replace the default frame widths with
the ones from the cookie. (Actually, the frameset definition is a
JSP, so I can access the cookie from there.)

But I was wondering if there is a generic approach so that I don't
have to write special code for each and every frame. Is there?

I'm also wondering if it is perhaps better to store the frame widths
in the HTTP session, rather than the cookies. (It would be easier to
access the frame widths from JSP in that case.) But it has proven
difficult to store the frame widths in the session from JavaScript, so
I abandoned that approach.

Suggestions appreciated.

Kai
Kai

[Philipp Lenssen]

Kai Grossjohann wrote:

Now the users are to be able to resize the frames.

WIBNI the webapp could remember the frame sizes across reloads and
frameset changes? For example, if the user resizes the menu bar frame
after login, then it should retain the width even after the user
chooses a search form, and after performing the search.

Why make it so complicated in the first place? Why use JavaScript,
Frames, Cookies? Can you point us to your page so we can see how it
must be frames?

[Kai Grossjohann]

"Philipp Lenssen" <in**@outer-court.com> wrote in message news:<bp*************@ID-203055.news.uni-berlin.de>...

Why make it so complicated in the first place? Why use JavaScript,
Frames, Cookies? Can you point us to your page so we can see how it
must be frames?

No, I can't point you to the page. I can't make pages available from
behind the company firewall.

It does not *have* to be frames, but the alternatives are even worse.
The objective is to make it look like the corresponding windows
application. The windows app looks like this (ascii art):

+----+------+-------+
| | | |
| 1 | 2 | 3 |
| | | |
+----+------+-------+

The left pane (labeled 1 in the above figure) contains a list of query
form names. Clicking on one of them shows the query form in the
middle pane (2). Entering data and submitting the form shows the
result list in the right hand pane (3). Each pane is separately
scrollable if the contents are too large.

The user is to be able to drag the vertical line between 1 and 2 with
the mouse to resize panes 1 and 2, and also the vertical line between
2 and 3 to resize panes 2 and 3.

If 1, 2, 3 are three frames, then I get the draggability of the two
lines for free.

I also tried to use a drag-and-drop JavaScript library to draw
vertical lines which are draggable. In that variant, each pane is
represented by a div (with scrollbars, if necessary), and dragging the
vertical lines uses JavaScript to frob the DOM such that the div
widths are adjusted properly. (Actually, I used a table with one row,
and each cell contains one div.) It's really painful to get it right.
And the library appears to fail in IE5.0.

Kai

[Philipp Lenssen]

Kai Grossjohann wrote:

I also tried to use a drag-and-drop JavaScript library to draw
vertical lines which are draggable. In that variant, each pane is
represented by a div (with scrollbars, if necessary), and dragging the
vertical lines uses JavaScript to frob the DOM such that the div
widths are adjusted properly. (Actually, I used a table with one row,
and each cell contains one div.) It's really painful to get it right.
And the library appears to fail in IE5.0.

Just to let you know, IE5 has drag-and-drop capabilities via DHTML.
Agreed it's a pain to use them. Maybe for your approach frames are
best. But why do users want to resize the frames? Wouldn't it be an
option to use simple positioned div's with relative width, filling the
whole window, which use overflow-property with scroll?

[Alan J. Flavell]

On Wed, 19 Nov 2003, Kai Grossjohann wrote:

No, I can't point you to the page. I can't make pages available from
behind the company firewall.
I think you just said "I don't want to talk about authoring HTML
for the World Wide Web". Well, that's fine by me.
The objective is to make it look like the corresponding windows
application.

Yup, that pretty much does it.

[William Tasso]

Kai Grossjohann wrote:

"Philipp Lenssen" <in**@outer-court.com> wrote in message
news:<bp*************@ID-203055.news.uni-berlin.de>...

Why make it so complicated in the first place? Why use JavaScript,
Frames, Cookies? Can you point us to your page so we can see how it
must be frames?

No, I can't point you to the page. I can't make pages available from
behind the company firewall.

It does not *have* to be frames, but the alternatives are even worse.
The objective is to make it look like the corresponding windows
application. The windows app looks like this (ascii art):
...

Was the windows app developed in-house? If yes, I think your best plan is
to build an ocx version of the app and let the users use it from within
Internet Explorer.

--
William Tasso - http://WilliamTasso.com

[Kai Grossjohann]

"Philipp Lenssen" <in**@outer-court.com> wrote in message news:<bp*************@ID-203055.news.uni-berlin.de>...

Kai Grossjohann wrote:

Just to let you know, IE5 has drag-and-drop capabilities via DHTML.
Well, maybe it's just the library I used that has problems with IE5,
or I used the library in the wrong way. (Google for "walter zorn drag
drop" and you'll find the library. It claims to work on IE4+. So
probably this is pilot error, rather than a bug in the library.)
Agreed it's a pain to use them.
Yep...
Maybe for your approach frames are
best. But why do users want to resize the frames? Wouldn't it be an
option to use simple positioned div's with relative width, filling the
whole window, which use overflow-property with scroll?

The draggability might be a dispensable feature, but there is so MUCH
of it in the windows application. I'm afraid that the webapp needs to
provide at least SOME of it...

Kai

[Kai Grossjohann]

"William Tasso" <ne****@tbdata.com> wrote in message news:<bp*************@ID-139074.news.uni-berlin.de>...

Was the windows app developed in-house? If yes, I think your best plan is
to build an ocx version of the app and let the users use it from within
Internet Explorer.

Well, I suggested to use a Java applet, which amounts to the same
thing I guess. There used to be a Java applet, but it had problems,
and now folks are afraid of fat clients...

And then, there is the cross-platform compat thing. I guess that
customers use Windows for the most part, but nevertheless it seems we
need to be able to advertise compatibility with Linux and MacOS and
stuff.

Kai

[Kai Grossjohann]

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> wrote in message news:<Pi*******************************@ppepc56.ph .gla.ac.uk>...

On Wed, 19 Nov 2003, Kai Grossjohann wrote:

No, I can't point you to the page. I can't make pages available from
behind the company firewall.

I think you just said "I don't want to talk about authoring HTML
for the World Wide Web". Well, that's fine by me.

Oops. You're saying I'm off-topic here. Is there a newsgroup
comp.infosystems.INTRANET.authoring.html?

The objective is to make it look like the corresponding windows
application.

Yup, that pretty much does it.

It does me, too. It's difficult for me to tell the difference between
misfeatures and bugs. Sometimes I see something nice and hear that it
is called a bug, and other times I see something awful and hear it
touted as a feature. Oh, well...

Kai

[Markus Ernst]

"Kai Grossjohann" <Ka*************@gmx.net> schrieb im Newsbeitrag
news:e8**************************@posting.google.c om...

I have been able to remember the frame width in a cookie by using
JavaScript and onunload events. I have also been able to frob the
frameset definition on load, to replace the default frame widths with
the ones from the cookie. (Actually, the frameset definition is a
JSP, so I can access the cookie from there.)

If you can rely on Javascript being turned on it might be the easiest way to
use only one frameset and load new pages cross-frame with Javascript.

HTH
Markus

[Daniel R. Tobias]

"William Tasso" <ne****@tbdata.com> wrote in message news:<bp*************@ID-139074.news.uni-berlin.de>...

Was the windows app developed in-house? If yes, I think your best plan is
to build an ocx version of the app and let the users use it from within
Internet Explorer.

But what if the user wants to use a decent browser instead?

--
Dan

[William Tasso]

Daniel R. Tobias wrote:

"William Tasso" <ne****@tbdata.com> wrote in message
news:<bp*************@ID-139074.news.uni-berlin.de>...

Was the windows app developed in-house? If yes, I think your best
plan is to build an ocx version of the app and let the users use it
from within Internet Explorer.

But what if the user wants to use a decent browser instead?

I know, I know, but on scanning this thread it became apparent this is an
intranet issue where user choice (often) plays second fiddle to the whims of
IT-support/admin. Sometimes the best course of action is to use the
tools/infrastructure available - if it applies.

--
William Tasso - http://WilliamTasso.com

[Kai Grossjohann]

"Markus Ernst" <derernst@NO#SP#AMgmx.ch> writes:

"Kai Grossjohann" <Ka*************@gmx.net> schrieb im Newsbeitrag
news:e8**************************@posting.google.c om...

I have been able to remember the frame width in a cookie by using
JavaScript and onunload events. I have also been able to frob the
frameset definition on load, to replace the default frame widths with
the ones from the cookie. (Actually, the frameset definition is a
JSP, so I can access the cookie from there.)

If you can rely on Javascript being turned on it might be the easiest way to
use only one frameset and load new pages cross-frame with Javascript.

And what if the user hits the reload button?

Also, I have several subtly different framesets, but maybe I could
work around this to make them all be similar enough for your approach
to work. But that leaves the reload problem.

Kai

[Kai Grossjohann]

Ka*************@gmx.net (Kai Grossjohann) wrote in message news:<e8**************************@posting.google. com>...

WIBNI the webapp could remember the frame sizes across reloads and
frameset changes? For example, if the user resizes the menu bar frame
after login, then it should retain the width even after the user
chooses a search form, and after performing the search.

[...]

But I was wondering if there is a generic approach so that I don't
have to write special code for each and every frame. Is there?

I've now done the following. In the frameset spec I do like this:

<frameset onload="restore_frameset('mainarea');"
onunload="remember_frameset('mainarea');"
...other.params...>
<frame ...>
<frameset id="mainarea" rows="1,2,3" ...other.params...>
...
</frameset>
</frameset>

Now remember_frameset gets the right element from the id, then
iterates over all child frames, and looks at their name. It also
splits the rows attribute. Then it generates a cookie frm_height_foo
for each frame foo which contains the right height. (If the frameset
specifies columns instead, it looks at the cols attribute and stores
in the cookie frm_width_foo.)

The restore_frameset function does similar, it goes through all child
frames, looks to see if there is a cookie for it, and if so, the size
is adjusted accordingly.

Matters are slightly complicated by the fact that IE 5 does not change
the rows/cols attribute when the user drags the frame separator.
Thus, I look at the document.body.offset{Width,Height} properties, if
available.

I hope this makes sense and perhaps it helps someone. Probably it's
quite stupid, but I'm just a newbie...

Kai