IMG and DIV properties don't stick after postback

Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

All Forums

Development Tools

ASP.NET

IMG and DIV properties don't stick after postback

Author

Topic

Billkamm
Posting Yak Master

124 Posts

Posted - 2006-02-13 : 14:55:52

I have several DIV and SPAN tags that the visiblity property is modified via client-side javascript and IMG tags where the src property is also modified via client-side javascript.

Whenever my page posts back to get more information all of these properties are lost. Is there a way to have non-form elements maintain their property information during postback?

jsmith8858
Dr. Cross Join

7423 Posts

Posted - 2006-02-13 : 16:51:31

Bill -- why don't you post these questions at an ASP.NET forum? I've taken an awful lot of my time to provide you with a lot of ASP.NET help here, but mostly you seem to ignore it and there probably aren't a lot of ASP.NET experts here at the sqlteam forums, so you might have better luck elsewhere. I'm happy to help with this stuff but apparently I am not giving you the answers you are looking for.

Billkamm
Posting Yak Master

124 Posts

Posted - 2006-02-14 : 08:27:14

I don't understand why you think I'm ignoring your advice. I appreciate your time and do read all of your replies. I do however view this as an ASP.Net forum and ironically I probably get replies more often on here and usually better quality than I do on other completely ASP.Net-oriented forums.

If you haven't noticed from some of my previous posts I do a lot of things the "wrong" way, because I'm fairly new to ASP.Net. For example when I first started this project I did a lot of Response.Write and had <% %> tags all over my HTML. I have since learned better ways that could have saved me a lot of time and trouble from the beginning. Now any time I run into a problem such as my one in this question my first thought is "well I could create do it this way, but what if there is an easier way I don't know about". After not finding an easier way through my books or google searches I post on forums to see if anyone else knows of an easier. Most of the time I know of another way of doing things, but I want to make sure I'm not missing anything first.

With this example I realize I can use hidden text boxes to store this information, but I wanted to see if 1) ASP.net should be saving this information for me and maybe there was something I did to cause it not to and 2) maybe there is some sort of property or method that I can use to tell ASP.Net to store this information in the viewstate.

jsmith8858
Dr. Cross Join

7423 Posts

Posted - 2006-02-14 : 08:48:53

Instead of just reading the posts, you might want to reply also with a quick "thanks" or "I got it now" or even what you did you solve your issue. that gives me some feedback, and also lets me know that I am not wasting my time.

You need to be sure you think about how a "post back" works and why it is not possible to change things randomly on a page with javascript and expect it to be there when it posts back. It sounds like you're on the right track -- you need to ensure that the data you want to persist is actually *posted* on the page, and therefore it needs to be in an element that gets submitted with a form. DIV's and SPAN's do NOT get submitted, so there is no way for the server to know that things have changed.

So, I think you have the right solution -- if you really need to do this, you must use Javascript to put all of your data into hidden form fields, but then when the form is posted, you will need to read those form fields and "re-do" the changes that were made in javascript on the server-side before returning the page after the postback to the client.

But, once again, I think it would pay off to step back and ask yourself if there is a better way to accomplish what you are trying to do without javascript. Also consider how well your app will work on browsers with javascript disabled or with limited javascript support.

SamC
White Water Yakist

3467 Posts

Posted - 2006-02-14 : 09:10:56

quote:
Originally posted by Billkamm

I have several DIV and SPAN tags that the visiblity property is modified via client-side javascript and IMG tags where the src property is also modified via client-side javascript.

Whenever my page posts back to get more information all of these properties are lost. Is there a way to have non-form elements maintain their property information during postback?

You can Google to find the code for this, but it is necessary for your JavaScript create a session-cookie to retain the "state" of the visibility you seek. On every <body onload="javascript("checkstate")"> (forgive my syntax), you check the state in the session-cookie and set the visibility on all objects again.

Billkamm
Posting Yak Master

124 Posts

Posted - 2006-02-14 : 10:02:15

jsmith8858: The site will be on my corporation's local intranet, so I know that everyone will be using MSIE. I have a check at the login page to make sure cookies and javascript are enabled and if they are not it gives them the number to the corporate help desk to have it turned on.

I use a lot of client-side javascript, because I have features such as collapse and expand buttons for sections of the page. I have so much interactivity on the page that I tried to put a lot of it in as client-side javascript to avoid having the user having to post back several dozen times for one page visit which in my opinion wouldn't be a very pleasant browsing experience.

SamC: Do you have any recommendation on search terms? Searching for JavaScript related questions returns a lot of results that hard to sift through.

jsmith8858
Dr. Cross Join

7423 Posts

Posted - 2006-02-15 : 09:20:31

Keep in mind that whether you store it in a cookie or post it back to the server, you will need to "recreate" those changes made the javascript on a postback. That is why I recommend posting the data to the server -- the server can then return the page exactly as it needs to look, otherwise it will come back in the "default" state and then the javascript will have to run client side to redo all of those changes that the user made, which will be slower and may cause the user to be confused as the screen changes back and forth.

SamC
White Water Yakist

3467 Posts

Posted - 2006-02-15 : 15:01:59

Server-side / Client-side

Particle / Wave

Republican / Democrat

Yin / Yang

function createCookie(name,value,days) { // Add a name=value pair to the session cookie
  if (days) {
    var date = new Date();
    date.setTime(date.getTime()+(days*24*60*60*1000));
    var expires = "; expires="+date.toGMTString();
  }
  else expires = "";
  document.cookie = name+"="+value+expires+"; path=/";
}

function readCookie(name) { // Read all the name/value pairs, return the value matching the name
  var nameEQ = name + "=";
  var ca = document.cookie.split(';');
  for(var i=0;i < ca.length;i++) {
    var c = ca[i];
    while (c.charAt(0)==' ') c = c.substring(1,c.length);
    if (c.indexOf(nameEQ) == 0) return c.substring(nameEQ.length,c.length);
  }
  return null;
}

jsmith8858
Dr. Cross Join

7423 Posts

Posted - 2006-02-16 : 08:47:04

quote:
Originally posted by SamC

Server-side / Client-side

Particle / Wave

Republican / Democrat

Yin / Yang

Sam, you know I think you're the greatest, but if you are trying to say that there is no difference executing code server-side and client-side other than an arbitrary programming preference, I could not disagree with you more.

SamC
White Water Yakist

3467 Posts

Posted - 2006-02-16 : 09:51:34

quote:
Originally posted by jsmith8858

Sam, you know I think you're the greatest, but if you are trying to say that there is no difference executing code server-side and client-side other than an arbitrary programming preference, I could not disagree with you more.

Rest easy Doctor. I'm a server-side guy myself. But the discussions I see about server / client remind me of other ongoing positional statements.

I do have one client-side JavaScript function which allows users to (1) enable / disable graphics and (2) change layout colors (to meet accessibility we support white text on black backgrounds).

These capabilities were met with server-side code in prior years, but now we feel the user-experience is much better without requiring a postback. Click! Black background. Click! White background. We re-engineered this server-side function with client-side JavaScript to meet a specific customer's performance requirement. Once it was done, we liked it so much we left it that way for all other clients from that time forward.

That, and JavaScript isn't seen as a security threat as it was several years ago.

Billkamm
Posting Yak Master

124 Posts

Posted - 2006-02-16 : 10:13:00

SamC: I'm personally a huge client-side guy. Most of the javascript I would be using client-side is for rollover and sorting and simple things like that. I think it is very annoying to the user to have postback to make a simple change to the website, so I personally like to have a lot of client-side code.

jhermiz

3564 Posts

Posted - 2006-02-16 : 10:35:21

quote:
Originally posted by Billkamm

SamC: I'm personally a huge client-side guy. Most of the javascript I would be using client-side is for rollover and sorting and simple things like that. I think it is very annoying to the user to have postback to make a simple change to the website, so I personally like to have a lot of client-side code.

You can eliminate a lot of post backs by using containers and panels in asp.net.

Keeping the web experience alive -- [url]http://www.web-impulse.com[/url]

RS Blog -- [url]http://weblogs.sqlteam.com/jhermiz[/url]

SamC
White Water Yakist

3467 Posts

Posted - 2006-02-16 : 10:45:55

quote:
Originally posted by Billkamm

SamC: I'm personally a huge client-side guy. Most of the javascript I would be using client-side is for rollover and sorting and simple things like that. I think it is very annoying to the user to have postback to make a simple change to the website, so I personally like to have a lot of client-side code.

I think you mean "to make a simple change to the rendered page"?

I feel myself being sucked into the black hole of server-side / client-side... HELP me! Jeff! Help me!

Bill, step away from the light-saber and use the force! Server-side kicks client-side's ass!

Billkamm
Posting Yak Master

124 Posts

Posted - 2006-02-16 : 10:57:44

SamC: You are thinking from a programmer's perspective. I'm thinking from an end user's perspective

jhermiz: thanks I will looking into those objects

jsmith8858
Dr. Cross Join

7423 Posts

Posted - 2006-02-16 : 11:52:14

Bill -- another thing to look at, since you mentioned it is for an intranet and everyone is using IE, is putting a smartnavigation="true" directive on your page to see how that looks.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconPage.asp

That might really help you out a lot.

Always remember, client side and server side code both have their places. For changing things "on the fly" for the user, of course you would often client-side code.

But for most everything else, I strongly recommend ~~ClientSide~~SERVER-side

since you have so many benefits, perhaps most importantly the fact that you know your code will be executed correctly, it is hidden, it is faster, it is compiled, strongly-typed, running in a known context, etc.

Either way, Bill, check out smartNavigation -- it is pretty cool and postbacks occur without users even knowing it.

jhermiz

3564 Posts

Posted - 2006-02-16 : 12:58:30

I think he meant strongly recommends server side.

Keeping the web experience alive -- [url]http://www.web-impulse.com[/url]

RS Blog -- [url]http://weblogs.sqlteam.com/jhermiz[/url]

Billkamm
Posting Yak Master

124 Posts

Posted - 2006-02-16 : 13:03:56

Nope he can't change it now "I strongly recommend ClientSide" it is lol

jsmith8858
Dr. Cross Join

7423 Posts

Posted - 2006-02-16 : 13:16:40