| 1:58 am on Dec 11, 2004 (gmt 0)|
haha. Went through this just the other day with a particularly difficult customer that insists on swimming against the stream, except my problem was remembering which layers were last visible.
| 3:09 am on Dec 11, 2004 (gmt 0)|
A backdoor approach that avoids cookies is to store a string as the window.name. Window.name is a read/write string that most pages never touch, except in the case of popups. To be compatible with NN4, avoid spaces or punctuation in the string.
| 4:58 am on Dec 11, 2004 (gmt 0)|
Wow I didn't think I would get useful help so quickly. I will try it out and let you know how it works. Thanks!
| 1:45 pm on Dec 11, 2004 (gmt 0)|
I've found that when a problem like this pops up it usually helps to look at the overall approach that's being taken. In other words, address the problem at the step BEFORE the step where the problem rears it's head.
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.
| 6:16 pm on Dec 11, 2004 (gmt 0)|
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?
| 4:21 am on Dec 12, 2004 (gmt 0)|
I'm trying to get the general idea of what you're doing.
Are you using a hidden iframe to act as an "agent" to reach out to the database?
(Also, I'm curious - why a right-click? And how does the user know to do that?)
And what visual styles are you changing? the color or what?
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.
| 7:36 am on Dec 12, 2004 (gmt 0)|
Sorry, but I wasn't too clear in describing my scenario. Yes, I am changing the visual style of the <td> elements. How the user knows to right-click is orthogonal to this problem I believe, so I won't go into it.
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.
| 5:12 pm on Dec 12, 2004 (gmt 0)|
Not orthogonally, I'm going to try to duplicate the problem you're describing.
I wanna see it.
| 6:34 pm on Dec 12, 2004 (gmt 0)|
OK twp, I see it. And I am working under the assumption that the iframe is reaching out to the server to make the changes to the database and then, when the request returns it changes the background color in the parent document. One td element at a time.
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.
| 1:25 am on Dec 13, 2004 (gmt 0)|
Here's a simple example using the window.name to hold the string for setting the values. Note that this is just an example and is inadequate to rely on in the event another site modifies the window.name (few sites do, though the Economist would be an example of one that does).
<!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>
| 6:52 pm on Dec 13, 2004 (gmt 0)|
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.
| 6:53 pm on Dec 13, 2004 (gmt 0)|
Thanks very much for the example that actually works. I'm not sure if I want to use the window.name, but it does appear to fix what I'm describing.
| 2:21 am on Dec 14, 2004 (gmt 0)|
Glad to be of assistance. I'm not really advocating using window.name, but it might be useful if the user is blocking cookies. Basically, a cookie would work the same way, though you would have a bit more overhead and you might have to be more careful about clearing the cookie values if new settings were chosen, depending on the persistence you choose for the cookie.
| 2:34 pm on Dec 14, 2004 (gmt 0)|
"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.
| 2:44 pm on Dec 14, 2004 (gmt 0)|
window.name and any other custom OOP solution are only good as replacements for session only cookies. there is no persistence alternative to cookies, sessions, or serverside logs of some or other sort.