Thursday, May 14, 2009

Email Casualty

Back when Gmail was still invite only and pretty new I managed to get an invitation and get my name without any numbers or symbols or abbreviations. It was great. The kind of email address you always hope for.

Now, years later I'm starting to regret it. There seem to be lots of Jakes out there and they keep using my email address.

It's been manageable up until today when I was forwarded some dirty cell phone pics obviously meant for someone else's Jake. I'm ready for a jake123abc@obscure.example.com so I don't get drive by emailed any more.

Here are some other examples of emails I've received:
  • Some random dudes vacation photos, on two separate occasions.
  • Paypal Signup - I was only momentarily tempted to make a purchase. I stopped getting these so I suppose the account owner realized their email mistake.
  • Adult Friend Finder - I had to go deactivate that one, I didn't want any more of those.
  • YouMail - a voice mail service, BTW, Jake...your coach left you a message. I logged in and changed the email address on that one, it accepted nomail@example.com. Don't you love it when they send your temporary password in an email!
  • Wine Dog - I'm just filtering this one until I decide to become an alcoholic.
  • And finally, I, a guy without a cellphone, got sexted. I guess you could say that's the nipple that broke the camel's back.
So, next time you're signing up for an email address consider it a blessing when your first choice isn't available and you have to pick xyz123abc2009@crazymail.example.com.

P.S. Teenagers -- If you don't want your dirty pictures posted all over the Internet for the whole world to see DON'T TAKE THEM!



HTML Controls in ASP.Net

The more I use ASP.Net the more I move toward (almost) plain old HTML.

For example:

<asp:Panel id="myPanel" runat="server">
I am in a Panel
</asp:Panel>
<div id="myDiv" runat="server">
I am in a div
</div>

I used to use Panels to conveniently show and hide blocks but I found that I've slowly been moving to using DIV tags with the runat="server" attribute. What's the difference? Well, with a div I get to see and control my markup. With the Panel I don't really know what is going to be rendered. I also get to apply CSS in a way that is consistent with the way I'm applying it to the rest of the page. It can be tricky to apply CSS to ASP.Net controls since I don't know what HTML they might render.

I've found that I don't need to be shy about using runat="server" on regular everyday HTML tags. I use it on TR tags for easy show/hide or server-side modification of attributes (like class or style).

I've also found that using runat="server" on input controls is often much more desirable than using the ASP.Net equivalents.

<asp:checkbox id="myCheckbox" Text="Check Me Out!" runat="server" />
<input type="checkbox" id="myInputCheckbox1" value="10" runat="server" /><asp:Label AssociatedControlID="myInputCheckbox1" runat="server">Check Me Out!</asp:Label>
<input type="checkbox" id="myInputCheckbox2" value="10" runat="server" /><label for="<%=myInputCheckbox2.ClientID%>">Check Me Out!</label>

Why use one over the other? I guess it just depends on what I want to do. The Checkbox control doesn't have a Value property and the HtmlInputCheckBox does. However, the HTML version doesn't have a Text property and I have to provide my own label. HtmlInputCheckBox gives my control over the markup but doesn't provide AutoPostBack.

This is also why I prefer the Repeater over controls like the DataList or GridView. With the Repeater I have control over the markup. And with some help libraries getting things done on the ItemDataBound event is pretty easy.

Just remember that you have options and that even in ASP.Net your run of the mill HTML tags can be empowered as well.

AJAX.Net

In the past (and in the present) I have used a custom built Ajax library for making my Ajax calls and handling the responses. It's simple, supports plain text, XML and JSON, and handles multiple requests, cancellations and errors properly.

In the less distant past I began using ASP.Net Update Panels and AJAX.NET libraries. In some cases they are convenient and easy. But I'm finding in most cases they are buggy, extremely limited and implementation doesn't really fit well with my style.

Now...most likely all my AJAX.Net difficulties arise from my limited experience with the library and my failure to familiarize myself properly with all the ins and outs of implementing it in my sites.

Anyhow, given my experience I recommend against using AJAX.Net and update panels and recommend sticking with a client side library like those found in jQuery or MooTools.

Here is a list of problems that make implementing and using basic AJAX.Net Update Panels difficult:

  • Updates are too heavy. The view state has to go back and forth. Even just to update one word on the page.
  • Inflexible when you move outside the box. For example, I only want to trigger an update panel update if there are 4 or more characters typed in a box. Now I have to implement my own client side event handlers and trick AJAX.Net in to making the update. If I have to do all that anyways what savings is AJAX.Net giving me?
  • Out of order responses. I often see out of order responses. Faster executing updates return before slower executing updates regardless of the order I called them in. Most often I see this when the application decides it has to restart and the longer executing first call often returns after the second call.
  • Poor error handling. I haven't found a way to gracefully handle errors. I can catch some but it doesn't seem to catch them all.
  • Dies after 1 error. If I have 1 AJAX.Net error all AJAX.Net stops responding and no panels will update until the page is refreshed.
  • Updates die for no good reason. I have a text field that triggers an update after some keystrokes. But if the user presses tab to move to the next field between the time when the update starts and when it returns then the update hangs. Monitoring the application shows that it does process the request but the client side just ignores it. I guess it has ADD.
  • Loss of state. Since an update panel nukes the contents of a div and replaces with what it just got back from the server I lose some UI state. If I've done any client side tweaking that dissapears but most often I just lose focus on the control I just changed. This is a nuisance for those that navigate the form with the tab key.
So, needless to say, I've gone back to my custom Ajax JavaScript library. I never have any of the problems described above. Some things are a little more work but the reliability is worth it.

To be fair here are the issues with using my own Ajax library:
  • Everything is difficult (not that difficult) because even simple updates require full programming unlike UpdatePanels which just need the markup and event handler.
  • Manual management. I have to remember to cancel outstanding requests so things don't get out of order and I have to handle updating the page with the response. It's just more work.
  • Non-standard. Good luck future developer who gets to maintain my project. I've coded it well but it's all custom so your experience with standard libraries won't help you here.
  • Full post backs. I'm a little lazy and so I just create a separate ajax.aspx page that handles my ajax requests and makes the expected response. It's not very ASP.Net-y and is probably pretty heavy since I'm doing a complete page request. In fact, this method takes me outside all of ASP.Net's help. I don't have access to controls or events. I have to pull data from Request.Form process it and respond. I sometimes end up with duplicate code and duplicate markup (especially if I'm being lazy).

Even given those issues I still like my library because of the fine grained control it gives me.