A lot of web developers suffer from dhtmlaphobia and wont dare use any form of client side scripting lest it alienate their users who run lynx or netscrap4.x... ;-)
(Although to be fair there are still quite a few of the later around. You will also probably hear the excuse that people switch off JavaScript. I reckon such users deserve all they get (or more to the point dont get(though Im sure they dont miss the advertising popups))) Certainly tab effects can be done easily in both ie5 and netscrap6 using styles and script - despite the many many bugs in ns6 in this area... -----Original Message----- From: Savantraj, Chennamakal Subramanian [mailto:Savant.Rcs@;ap.sony.com] Sent: Wednesday, November 13, 2002 17:59 To: 'Struts Users Mailing List' Subject: RE: Client-side Caching??? Why can't you try pure DHTML solutions for providing this kind of effects. Of course you may have to sacrifice cross browser compatibility some times. Just making some hide and show mechanism you can simulate Tab effect easily. -----Original Message----- From: Jon Ferguson [mailto:ferguson@;ieee.org] Sent: Wednesday, November 13, 2002 5:49 PM To: Struts Users Mailing List Subject: Re: Client-side Caching??? 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> ------------------------------------------------------------------- This email is confidential and intended only for the use of the individual or entity named above and may contain information that is privileged. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or telephone and destroy the original message. Thank you. - This mail is sent via Sony Asia Pacific Mail Gateway. ------------------------------------------------------------------- -- 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>
