Entries Tagged 'Work' ↓

This weekend has been a nice relaxing weekend for me and so when I got back home this afternoon (on Sunday the 16th), I was in a great mood to refactor some of my kiosk code base. Now, I should start by saying, I decided to refactor code instead of write new code tonight because I wanted to lessen the number of files that needed to load in the Ajax functionality.

Kiosk, uses Ajax in interesting ways to provide a better experience, but with that, the Ajax applications were built as each page was assembled. This caused functionality across pages to get a bit messy or functionality shared across pages to get thrown into individual files. Well the problem with individual files, is that is yet another file for the browser to download.

So before I get any further, let me discuss refactoring and how it can solve many performance binds your application may be experiencing.

To start off, refactoring is taking common code, or code that is used across pages or frequently and moving it to a more global location so it can be called easier and the code only has to be written once.

So where can this help?

• First of all, by refactoring code into a single global file, you can limit the number of HTTP requests if that file is accessible via the web. Since your common code is in a single file, the browser only has to fetch that code once, and will then likely cache that file for each page after, giving you even better performance.
• Secondly, by placing the common code in a global method/function, you are writing less code. As now when you need to call that code on your second page, it is already written, so just call the function. Otherwise, you would need to write the code all over again.
• Thirdly, less code equals smaller files. By refactoring your code, you can have smaller file sizes and in turn that is quicker to download, quicker to parse, and quicker to execute.

Now in my situation, I took about 4 JavaScript files and combined them into a single file adequately named “general.js”. The file contained code to automatically log the user out after a set amount of inactivity in the UI (User Interface). Secondly, it contained the version checking mechanism calls that see if they are running the latest version of the software. Unfortunately, those are the only two things it does right now, but as the project progresses, I am sure more utilities will get added in this file.

My next task is to refactor the Data Grid functionality so it is 1) XHTML, 2) easy to build complex columns with complex rows, 3) customizable by identifying StyleSheet classes for the columns and rows. Hopefully, I can get my head around this idea and get it working with little trouble to the programmer.

So what can you think of that you need to refactor? What performance gains do you suspect you will achieve with the refactoring you do? Any performance markers?

When you write a Server Control and write it well, it pays off immensely. Today, I needed to rework our Custom Defaults screen (a screen that allows each user to define defaults for our quoting screens to use each time they write a new quote). All of the fields on the Custom Defaults screen exist in the quote (duh, why would we provide something that didn’t? ).

Since everything in the quote is a server control, it was just drag and drop the controls onto the Custom Default page and it would act 100% like it does in the quote. It could not have gone any faster, I probably only spent close to 5 minutes setting up the design and flow and 30 minutes getting the code behind functionality to work.

Thus, harness the power of Server Controls as they can be reused across numerous applications with little trouble and little programming.

Today, Aaron and I were wondering if ViewState actually works properly in .NET. For example, in .NET you have the option to disable ViewState in the web.config file, the page directive, or on each control individually. However, using any of the three methods or any combination continuously results in “__VIEWSTATE” appearing as a hidden field in the form!

The problem gets worse when you try to submit the form to another page by overriding the form’s action. This throws an “ViewState is corrupt or invalid for this page.” error. We finally got around it by hacking a JavaScript event to empty the “__VIEWSTATE” hidden field so it had nothing in it before the form actually submitted the page. But is that the only way to get rid of ViewState?

Code to cause ViewState corruption:

<script type="text/javascript">
    window.onload = function()
    {
        document.getElementById('Form1').onsubmit = function()
        {
            document.getElementById('Form1').action = '/another_project/another_page.aspx';
        }
    }
</script>

How, we got around it:

<script type="text/javascript">
    window.onload = function()
    {
        document.getElementById('Form1').onsubmit = function()
        {
            var inputFields = document.getElementsByTagName('input');
            for (var i = 0; i < inputFields.length; i++)
            {
                if (inputFields[i].name.toUpperCase() == "__VIEWSTATE")
                {
                    inputFields[i].value = ""; // Empty the ViewState hidden field to stop it from carrying on to the next page
                    break;
                }
            }

            document.getElementById('Form1').action = '/another_project/another_page.aspx';
        }
    }
</script>

Anyone else have a problem like this?