Peter, Thanks for your feedback on your experiences with frames. It is reassuring to know I'm not the only one.
I have interspersed my comments below. Vaughan. > -----Original Message----- > From: Peter Pilgrim [mailto:[EMAIL PROTECTED]] > > I found HTML frames very problematic. > > I had to action that forwarded to the frameset , action > forward ("promptFrameset" ). > This HTML document is the frameset document that reloaded all > the frames. > This meant that the forms in the sub frames had to set the > targetFrame to "_top" > as well. I have done something similar. > > I think you will have to experiment with JavaScript handlers > on the html:form > ( the latest Oreilly book is very help and well as the > Professional JSP Site book, > which I dont have, has a chapter devoted to HTML Frames. ) Yes, I have the JSP Site Design book. It does have a nice chapter on frames. I think one workaround to the observed inconsistency apparently related to the use of Struts forwards might be to avoid them altogether in conjunction with frames, by using JavaScript, as the tags described in that book do. I have experimented with the onLoad( ) handler in the frameset. This may present another possible workaround route. > > I had a problem where I had a javascript HTML Buton that > simultaneous submit Forms in two different Frames, but targeted > the same frame. I found race conditions of the response. I > could not guarantee the output order of the target frame , > was A then B, or > B then A. In the end I remove the HTML Button functionality entirely. No, the order in which these requests are submitted to the browser cannot be predicted. > > Frames are useful, but I feel that the current X/HTML specification > is starting to show its old age, because us, professional developers, > are now pushing the limit with this technology. What I would > love in HTML 5.0 is a new <combobox> selection, and the ability > to have split scrolling tables, like with Excel, or StarOffice, coming > from financial background. > > > Oh well. > > HTH > > -- > Peter Pilgrim ++44 (0)207-545-9923 > > ............................................ Swamped under > electionic mails > > > ---------------------------------------- Message History > ---------------------------------------- > > > From: "Vaughan Jackson" <[EMAIL PROTECTED]> on > 09/01/2002 17:14 PST > > Please respond to "Struts Users Mailing List" > <[EMAIL PROTECTED]> > > To: "'[EMAIL PROTECTED]'" > <[EMAIL PROTECTED]> > cc: "Vaughan Jackson" <[EMAIL PROTECTED]> > Subject: Help! Differences in Browser Behavior for Reloading > Frameset Via Struts Action. > > > Hi, > > Has anyone else observed the following behavior, and if so, > could they explain it to me? Better still, could they explain > how to avoid it? Or am I going mad? > > To summarize, this is what I see happening (details below): > > 1. If I go straight to the frameset page, invoke an action on > one of its > child pages, > then reload the frameset, the child request I see invoked > during the reload > is that > for the last request invoked on the child page, rather than > that previously > invoked > for that child page by the frameset's frame's src parameter. > This is the > same for both > Internet Explorer 6.0 (IE) and Netscape 6.2 (NS). > > 2. If, on the other hand, I go to the frameset page by > submitting an action > that struts > looks up in struts-config.xml, then forwards to that same > frameset page, the > exact > sequence of requests submitted by the browser resulting from > the same user > actions > seems to vary. Specifically, the child page request submitted > as the result > of the > reload/refresh seems to be that originating from the > frameset's frame's src > parameter > for IE, but that submitted for NS is still that for the last > request invoked > on the child > page itself. > > > --<CUT>-- > > > > > -- > > This e-mail may contain confidential and/or privileged > information. If you are not the intended recipient (or have > received this e-mail in error) please notify the sender > immediately and destroy this e-mail. Any unauthorized > copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
