Stories about Software


You Can Use GhostDoc’s Document This with JavaScript

Editorial Note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, have a look at GhostDoc for your code documentation and help file generation needs.

If you haven’t lived in a techie cave the last 10 years, you’ve probably noticed JavaScript’s rise to prominence.  Actually, forget prominence.  JavaScript has risen to command consideration as today’s lingua franca of modern software development.

I find it sort of surreal to contemplate that, given my own backstory.  Years (okay, almost 2 decades) ago, I cut my teeth with C and C++.  From there, I branched out to Java, C#, Visual Basic, PHP, and some others I’m probably forgetting.  Generally speaking, I came of age during the heyday of object oriented programming.

Oh, sure I had awareness of other paradigms.  In college, I had dabbled with (at the time) the esoteric concept of functional programming.  And I supplemented “real” programming work with scripts as needed to get stuff done.  But object oriented languages gave us the real engine that drove serious work.

Javascript fell into the “scripting” category for me, when I first encountered it, probably around 2001 or 2002.  It and something called VBScript competed for the crown of “how to do weird stuff in the browser, half-baked hacky languages.”  JavaScript won that battle and cemented itself in my mind as “the thing to do when you want an alert box in the browser.”

Even as it has risen to prominence and inspired a generation of developers, I suppose I’ve never really shed my original baggage with it.  While I conceptually understand its role as “assembly language of the web,” I have a hard time not seeing the language that was written in 10 days and named to deliberately confuse people.

Read More


How to Disable Controls During Postback in ASP

The other day, I was working on a page in a webforms app where a postback, triggered by a button click, kicked off a bit of processing that would run from 10-20 seconds. While this is going on, it makes sense to disable the clicked button and other controls, for that matter. Since the processing occurs on the server, the only way to achieve this effect is by disabling the buttons and other controls on the client side, by using javascript. The following is the series of steps leading up to getting this right. If you just want to see what worked, you can skip to the end.

The first thing I did was find a bit of jquery that would disable things on the page. I put this into the user control in which I was doing this:

From there, I found that the way to distinguish between a server-side click handler (“OnClick” property) and a client-side one was to use OnClientClick, like so:

Here we have some standard button boilerplate, the server side event handler “SearchButton_Click” and the new OnClientClick that triggers javascript invocation and our jquery implementation. I was pretty pumped about this and ready to have my search button disable all client side controls and disable them until the server returned a response. I fired it up, clicked the search button, and absolutely nothing happened. Not only was nothing disabled, but there was no postback. After some googling around, someone recommended adding “return true;” after the disableOnPostback() call. Apparently any intervening client side handler not returning true is assumed to return false which stops the postback. So here is the new attempt:

This had no discernible effect, and after some searching, I found that the meat of the issue here is that disabling the button apparently also disables its ability to trigger a postback. We need to tell the button to fire the postback regardless, which apparently can be accomplished with UseSubmitBehavior=false as a property.

I tried this and, finally, something different! Only problem was that it was a partial success. The disabling of controls finally worked, but the postback never happened. On a hunch, I took out the return true and arrived at my final answer:

This combined with the jquery at the top of the page did the trick. So if you have a button that triggers a postback with a lengthy operation and you want to disable all controls until the operation completes and returns a response, this should do the trick. I am not yet an expert in under-the-covers webforms particulars, so the theory is still a little hazy on my end, but hopefully this helps anyone in a similar position to me. Also, if you are an expect in this stuff, please feel free to weigh in on the theory at play here.

On final thing that I’ll mention is that I did find something called Postback Ritalin during my searches. This seems to offer a control to take care of this for you, though I didn’t really want to introduce any third party dependencies, so I didn’t try anything with it myself.

By the way, if you liked this post and you're new here, check out this page as a good place to start for more content that you might enjoy.


Speeding Up DaedTech

As I get back into doing web development more and more these days, I’ve started to pay attention to some of the finer points, such as not having a sluggish site that turns off visitors. To that end, my Trello Board for this site had a card/story sitting in the “To Do” bucket for speeding up DaedTech’s load performance.

The first thing that I did was visit GTMetrix and run a baseline to see if subsequent things that I did would improve performance. From there, I installed W3 Total Cache which is a WordPress plugin that provides a whole bunch of functionality for speeding your site, mostly revolving around setting cache settings. After a bit of poking around and research, I figured out what was going on, and I enabled settings that helped with some low hanging fruit.

This included “minification” of CSS and javascript, a process whereby the whitespace is compressed out of these things as they’re sent from the server, thereby reducing the total amount of data sent (and thus time to process that data on the client side before displaying it). It also included optimizing the caching settings that the site suggests to returning visitors so that pages, styles, media, etc are stored locally on your machine as much as possible, which prevents reloads. This also setup the further use of GZip for further compression.

For improvement in the future, I installed a plugin called WP-Smush.it that will use the Yahoo utility for image compression to any file I add through the media library. This seems convenient enough that I should probably start adding files through the media library in general rather than simply putting them on the server and linking to them at their full local URL to get this functionality.

While I’m at making resolutions to improve speed going forward, here are some other tips that I’ve picked up today:

  1. Serve scaled content. Meaning don’t put up some huge image that the browser downloads only to use CSS or HTML in to tell the client to shrink it down. Send over the smallest possible image.
  2. Favor using my own images instead of embedding them from other sites. This lets me control the cache expiration suggested to the browser and the size as well. With hyperlinked images, I don’t have this control.
  3. Specify the image dimensions rather than simply accepting the default.
  4. Consider using image “spriting” to combine images such as the gaggle of social buttons into a single “image” to reduce the amount of stuff getting sent over the wire.
  5. Consider using a content delivery network to store your resources in places closer to site readers.
  6. Try to limit the number of things that make HTTP requests (like social media buttons)
  7. Use a utility to defer javascript execution so that it doesn’t block page load

I’m no web performance guru by any stretch. This is just what I pieced together in a morning after saying “I want my site to load faster”. I’m hoping that people in a similar situation to me will see this and realize that there is some pretty low hanging fruit to be picked here and that it isn’t terribly complicated to do so.