I think I agree with you Andrew. Especially since web-applications often are targeted at a sub-group of users and may carry a stipulation of using a limited range of browsers and setup...
Having said that.. the solid MVC architecture in struts can sometimes make me forget I'm programming on the server :-) Cheers, Jon ----- Original Message ----- From: "Andrew Hill" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Wednesday, November 13, 2002 10:13 AM Subject: RE: Client-side Caching??? > 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> > -- To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
