17 July, 2008

i spent good part of the day building a little control to upload documents for our crm tool today. because i wanted to give the customer the ability to decide how many files she wants to upload at runtime, i put a little "add another file button" on the control, which would dynamically let the user add another file.

as soon as i had this dynamic functionality built, i threw it on the control where it was supposed to go (yes, my control was nested inside another control, which was then placed on the page where the upload functionality was needed). unbeknown to me, the person who had written this page was also dynamically loading his control; unfortunately, he was only loading the control on the pageload, and not on the postback.

for about an hour i kept trying to figure out why the button onmy control wasn't firing its events. finally, in frustration, i decided to step through all of the code: as soon as I saw the pageload i realized what was going on: my control wasn't firing events on the postback because it wasn't even there when the page submitted!

most developers know that web-apps are stateless, but i think we fail to internalize what this really means. we assume that once we declare a variable, it will remain there as long as it's in scope. i'm not trying to blame my co-worker; in fact, i've made this same mistake several times (which is probably why i recognized it almost immediately). i think the problem is we first learn to program in statefull environments, and then make the switch to the web without fully understanding the implication of moving to this new environment.

anyhow, i'm somewhat upset over the fact that i didn't get to finish the control today. i'm planning on getting up early tomorrow, coming in before anyone can bug me and getting the control done - that is until i run into the next nuisance from the stateless web, i guess.