Hi Eelco, I'm using tiles to create tabbed panes: | A | B C | etc...
The user can select any pane to view other aspects of the application.. much like you would do in swing. SO the traversing IS inside the application. Also I put an Apply button on each page then store the page state in a session on the server. So the following works flawlessly: 1)user edits A 2)user applies A (changes are viewed) 3)user selects the B tab - showing the B page 4)user selects the A tab - showing the changed A page. But because nothing happens on the server without the apply.. the scenario does Not work if you leave out step 2. A software engineer wouldn't expect it too.. but a user would - especially coming from using a GUI app. The nature of the program requires as few clicks as possible.. and a lot of information.. It's not really a workflow that I can see cause It's not sequential.. The only way I can see solving this is to use JavaScript to capture edited but un-applied form data behind the scenes. Or reworking the application in someway to enforce the apply. The former feels like an enhancement on the Struts form tags.. which I'm willing to investigate if I'm not barking up the wrong tree! Cheers, Jon ----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Tuesday, November 12, 2002 9:06 AM Subject: RE: Client-side Caching??? > > Jon, > > How does the client jump to page B? If this is done outside the scope of > your application (e.g. by selecting a bookmark) there is really not much > that can be done about it (I wouldn't speak about an HTML limitation, but > rather about a user limitation). If it's done inside the scope of your > application (e.g. a button, tab or link you provided), you could easily > submit the form to the server (without really applying the changes) and > keep the form in your session, for the next time the client selects page A. > > Regards, Eelco > > > > > > "James Mitchell" > <[EMAIL PROTECTED]> To: "Jon Ferguson" <[EMAIL PROTECTED]> > cc: "Struts Users Mailing List" <[EMAIL PROTECTED]> > 11-11-2002 13:19 Subject: RE: Client-side Caching??? > Please respond to > "Struts Users Mailing > List" > > > > > > Hi Jon, > > This really belongs on the struts-users mailing list. If you are not > already subscribed, you should do so. I'm sending a copy there for further > discussion. > > > James Mitchell > Software Engineer/Struts Evangelist > http://www.open-tools.org > > "If you were plowing a field, which would you rather use? Two strong oxen > or > 1024 chickens?" > - Seymour Cray (1925-1996), father of supercomputing > > > > -----Original Message----- > > From: Jon Ferguson [mailto:ferguson@;ieee.org] > > Sent: Monday, November 11, 2002 6:46 AM > > To: Struts Developers List > > Subject: Client-side Caching??? > > > > > > Greetings all, > > > > A web-application issue I'm trying to solve: > > > > Assume you have a complex web-app that requires links and input between > > several web-forms. The user can jump around.. and to make the > application > > compelling.. Must be able to. Here's a scenario of interest: > > > > 1) User edits page 'A' but does not submit the form > > 2) User jumps to page 'B' to fill in other details or lookup something > > 3) User returns to page 'A' expecting to see his edits. > > > > Problem: since page 'A' was not submitted the server never saw > > the edits and > > so reconstructs the page with the old data. User sees this as a bug > > (developer sees this as a limitation of HTML!!!). > > > > Right now the only clean solution to this kind of problem seems to be: a) > > use Java with WebStart, b)use Macromedia's Flash with server-side > > extensions, c)Introduce some sort of client-side caching as part > > of Strut's > > Form tags or d)change the layout such that the client-naturally applies > > changes before proceding. > > > > Ideas? > > > > Thanks in advanced, > > Jon > > > > > > -- > > To unsubscribe, e-mail: > <mailto:struts-dev-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org > > > > > > -- > To unsubscribe, e-mail: < > mailto:struts-user-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: < > mailto:struts-user-help@;jakarta.apache.org> > > > > > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. If you have > received it in error, please notify the sender immediately and delete the > original. Any other use of the email by you is prohibited. > > > -- > To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org> > > -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
