> -----Ursprüngliche Nachricht-----
> Von: Peter Alfors [mailto:[EMAIL PROTECTED]]
> Gesendet: Donnerstag, 26. Juli 2001 15:54
> An: [EMAIL PROTECTED]
> Betreff: Re: Struts and Frames
>
>
> The struts tags have a target attribute that you may set to
> point to the desired frame. Since the target is actually
> handled by the browser (as where to display the results),
> there isn't really much "handling" to be done by struts. Our
> site has 3 frames within a frameset. We have not experienced
> any problems. However, we are also not moving in and out of
> the frames. I guess it may prove a little more difficult if
> you want to go from a frameset to a single frame, then back
> to a frameset with dynamically specified pages. Even so,
> this is not really a struts issue, but more of an app design issue.
Thanks for your answere Peter. Meanwhile I have been thinking and
prototyping the Frames idea a bit more through. One thing I would like
to have is that only those frames get updated, that really need to. But
a get/post always only updates one window. So I have been thinking about
the following design:
The top level frameset consists of a frame for the actual page
("NonHidden") and a hidden frame ("Hidden"). In "NonHidden" there might
be other arbitrarily deep nested frames and framesets. Whenever
something happens (a get or post) the action mapping triggers the right
functions to change the buisness objects and the always forwards to the
same servlet. The target of each and every post/get will be Hidden. The
servlet that is activated by each action, does not produce any code to
display, but instead it has a JavaScript "onLoad" feature, that will
reload every frame that needs to be changed. The list of frames that
need to be reloaded are determinded at runtime (not sure how this will
be implemented). Anyway the key is to put the Document (from the
Document/View pattern) always into the session. If there is a view to
display a menu, the session will have a "Menu" attribute. It is this
attribute that the actions change if they need to and is this attribute
the views read to produce HTML.
Does that design strike anyone with a little more experience in web app
design? (; One obvious drawback is that the browsers back button would
not work, because it will not change the Document attributes in the
session scope.
Tia,
Andreas