Welcome to WebmasterWorld Guest from 126.96.36.199
Forum Moderators: open
This is an Intranet app, so I'm targeting IE 6. I'm using
parent.document.getElementById(tdId).className = style;
where tdId is some element id and style is the new style. Again, I can change the styles of say 5 of them, click on a link to go to another page, and when I click the "Back" button, 4 out of the 5 (all but the most recently changed one) will revert to their original styles.
Is there a way to have them all remember that they got changed?
Do you have to use the element's class to effect the change? Can't it be an inline style using the style object.
I realize rethinking this might take some time but it might be a lot less work in the long run.
Let us know how you resolved this.
I have a calendar of "events" that get read from the database. Each event is a <td> element. I would like the user to be able to "cancel" events by right-clicking the <td> element. The right-click is targeted at an <iframe> to do the database update, then it goes and changes the style of the <td> to give feedback that the cancel has taken place. I don't want to reload the entire page after each cancel because that would be too slow in case someone wanted to cancel a lot of things in succession.
In response to your question about the inline style, I'm not sure I understand your point. I'm using <td class="someClass"> to set the initial style. Would using the style property somehow alleviate this problem?
Anyway - CSS uses a certain internal logic to resolve conflicting styles. In short, some rules are more powerful than others.
For instance, setting an inline style like this:
<div class="redfont" style="color:blue;">TEXT</div>
will override setting it by class in the style sheet like this:
The color of the word TEXT will be blue.
parent.document.getElementById(tdId).style.color = "red";
Then it will definitely be red no matter how the className has changed.
Now, I don't know if it will prove to be any more "sticky" than changing the className but my instincts tell me there's gotta be an answer to this some way, somehow without resorting to too much hackery.
I'm using the class to specify the background color of the <td> element. If the event is active, it has one class, otherwise it has the cancelled class. The hidden iframe does hit the database, and changes the class of the event accordingly. This part I think I have working fine.
The problem is that I will perform a series of these changes of classNames, visit another page, click the "Back" button, the classes will revert back to the classes they had when the page was first loaded.
If the page starts out:
[red class][red class][red class][red class]
and I dynamically change the first, second, and last (in that order):
[blue class][blue class][red class][blue class]
I will visit another page, then click the "Back" button and the page will appear
[red class][red class][red class][blue class]
which is not how I left the page. This is what I meant by "stick". It seems to remember the last change but not anything before that. I hope that clarifies my problem.
Some way has to be found to make the page in the iframe "remember" all of the td elements it has changed in the parent document. This could be done on the server side or you could go for a cookie that updates itself every time a change is made created by the page in the iframe.
However, I think you may be asking for trouble by allowing the user to make changes, drift away to other pages, and then come back. I mean, by then, the "session" for making these changes is over, right?
Better to expire the page and make a fresh call to the server I think.
Hope this helps narrow the problem down.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
<div id="divOne" class="rd" onclick="chgCls('divOne','bl');"></div>
<div id="divTwo" class="bl" onclick="chgCls('divTwo','gr');"></div>
<div id="divThree" class="gr" onclick="chgCls('divThree','rd');"></div>
And I'm asking for trouble somehow? I think a user should be able to make changes, go somewhere else, come back, and have the changes be maintained.
"And I'm asking for trouble somehow? I think a user should be able to make changes, go somewhere else, come back, and have the changes be maintained."
Please don't blame me. This all has to do with the basic nature of http. You can complain about it all you want but you're not going to get data of any kind to persist when the user leaves the page without either writing a cookie or making a fresh call to the server. This problem was why Netscape came up with cookies to begin with.
I wish there was an easier way.
Other than that, live and learn, 'cause I didn't know window.name could be used to house data and have it persist.