While working on a project in ASP.NET, I needed a function that would retrieve the domain of the current url, however, I also wanted the function to also retrieve the correct ASP.NET development web server path when developing in Visual Studio. After consulting Google, I ran into this old post on Rick Strahl’s blog about the Request.Url object.

After some experimenting, I created a web page in ASP.NET 2.0 that showed what parts of the URL could be returned using different calls. Consult the following in the page load event.

    protected void Page_Load(object sender, EventArgs e)
    {
            Response.Write("Request.Url.AbsolutePath= " + Request.Url.AbsoluteUri);
	    Response.Write("<br>");
            Response.Write("Request.Url.AbsoluteUri= " + Request.Url.AbsoluteUri);
            Response.Write("<br>");
            Response.Write("Request.Url.GetLeftPart(UriPartial.Authority)= " + Request.Url.GetLeftPart(UriPartial.Authority));
            Response.Write("<br>");
            Response.Write("Request.Url.GetLeftPart(UriPartial.Path)= " + Request.Url.GetLeftPart(UriPartial.Path));
            Response.Write("<br>");
            Response.Write("Request.Url.GetLeftPart(UriPartial.Scheme)= " + Request.Url.GetLeftPart(UriPartial.Scheme));
            Response.Write("<br>");	
            Response.Write("Request.RawUrl= " + Request.RawUrl);
            Response.Write("<br>");
            Response.Write("Request.Path= " + Request.Path);
            Response.Write("<br>");
            Response.Write("Request.ApplicationPath= " + Request.ApplicationPath);
            Response.Write("<br>");
            Response.Write("Request.ResolveUrl= " + ResolveUrl("~/dealer/default.aspx"));
            Response.Write("<br>");
            Response.Write("GetAuthorityApplicationPath= " + GetAuthorityApplicationPath());
    }

    private String GetAuthorityApplicationPath()
    {
        return String.Concat(Request.Url.GetLeftPart(UriPartial.Authority), Request.ApplicationPath);
    }

The function GetAuthorityApplicationPath() is what I needed in the end to dynamically retrieve either the domain in a production environment or the development web server url while running Visual Studio (eg. ‘http://localhost:1234/WebDirectory’)

Lately I’ve been tasked with writing an Administration interface that’s very client heavy for a web application. It uses the Extjs framework and its widgets for building the GUI, Django + Python for the application tier, and PostgreSQL for the database end. We’re using Apache and Ubuntu Server as our platform. The entire application stack is open source, so the acquisition costs for starting development is nil.

In the past few weeks, I’ve developed more insights into the advantages of developing on a completely open source stack. The newest pro I’ve discovered is the documentation and active communities in the larger and popular projects. I know a lot of MS developers moan about the lack of adequate support available on some open source projects, but it’s not true of all them out there. When choosing components for your system, it’s almost a given that strong community support is a requirement. Fortunately in OSS projects, the utility of a project and the general following behind it go hand in hand.

I can recommend with confidence that the community support behind our application stack (Extjs, Django, Python, PostgreSQL) for our system is strong and adequate for any web application projects that you may want to pursue

Tonight I was wrapping up a deployment for a feature that was heavily dependent on javascript. After running my first batch of tests on Firefox, everything passed without a hitch. Then I ran my tests on Internet Explorer 7 and…. nothing.. literally a blank page rendered on my screen. Thus began my latest saga of fixing compatibility issues between browsers.

The first problem was that my scripts were either being downloaded and not executing, or were not downloading at all. I checked if the javascript files were being retrieved by using program called Fiddler2. This program intercepts all HTTP requests  and responses from Internet Explorer. After running the program, it confirmed that my files were being downloaded. So, this means the files were not being executed. After staring at my html code which looked like the following:

...
<body>
<script type='text/javascript' src='/file.js' />
</body>
....

I immediately remembered that Internet Explorer doesn’t render javascript references unless you specify the complete tag. Why? I suspect its because I didn’t specify the doctype in the html tags. So to fix that problem, I changed the script tag to look like this:

...
<body>
<script type='text/javascript' src='/file.js'></script>
</body>

However, that was not the end of my javascript problems with Internet Explorer. After running the javascript, I ran into an error regarding an undefined element in an array. My first thought was that this couldn’t be. The script ran flawlessly in Firefox. After some debugging, I concluded that the Javascript engine in IE interprets text representations for arrays differently than Firefox. The evidence that lead to this conclusion came from comparing the array length returned in Firefox versus Internet Explorer. Firefox’s length was 3, while Internet Explorer’s was 4.

My Firefox-only-array looked something like this:

array = [ {id:1,name:'hi'}, {id:2, name:'hello'}, {id:3, name: 'greetings'}, ]

Turns out that last comma in the array throws off Internet Explorer and causes it to increment that length an extra tick. The fix would be to remove that last comma. The fixed code looks like this:

array = [ {id:1,name:'hi'}, {id:2, name:'hello'}, {id:3, name: 'greetings'} ]

After sitting down and creating a javascript client, I have to say – this really sucks. I guess moving to a heavier client tier is a natural progression of web development. Back in 1996 or so when I was still in grade school, I started messing around with HTML and basic CGI scripts for creating dynamic web pages. About 2 years later, MySQL became really popular and the first database generated web sites started to appear. The big argument back then was whether application logic should be done in the database end or in the application tier. The languages and platforms I was aware of in the open source world were Perl and PHP3 – both were equally terrible web development tools. These weren’t the only open source tools out there at the time, rather quite the opposite. There was a huge plethora of different web platforms out there. Some still exist but still obscure – others just obscure. Let’s just say things were weird because everyone was still trying to figure out the best way to develop web front ends. For example, it wasn’t unheard of to hear SQL being used to generate HTML.

After PHP4 came out, there was an explosion in web development around the PHP, MySQL, and Apache application stack. About this time, most of the dynamic page generation got moved to the application tier.  Fast forward about 6 years later to the present, we’re seeing more of the page generation executed in the web browser using Javascript or some other platform built into the browser. There are numerous advantages that can be gained by moving page generation to the client: lower load on the servers, improved visual enhancements, and faster execution speed. However, developing interfaces in javascript still feels immature. To me, client side development in javascript is about equivalent to what PHP4 was back in 2001 – it does the job but has a lot of room for improvement.

This doesn’t mean the javascript engines found in IE and Firefox aren’t mature, its actually quite the opposite. Since Javascript has been incorporated in the browser since the 1990s, the engine is very mature and stable. It’s just new requirements and forms of usage for javascript has changed since its original inception, hence why I think the current implementation seems incomplete. By incomplete, I mean issues such as browser compatibility, the occasional memory leak, and I still think development tools have room for improvement, like code completion and debugging.

The current application I’m working on uses the ExtJs framework for generating the Admin UI and Django as the middle tier for parsing requests between the client and the database. So far, the combination is working well.

Today I was trying to find the location of my chat logs for gaim in Ubuntu and noticed that none of my logs were being found through the File Search program (‘Places’ -> ‘Search for Files’). After digging through a few Google queries, I ran into a blurb about hidden folders prefixed with a period.  It turns out all personal preferences user specific files for your applications are stored in directories with this notation ‘/home/user_name/.program_name’. So all my personal files and settings related to gaim would be stored in ‘/home/alex/.gaim’.

The File Search program ignores hidden files by default. In order to search hidden files, click on the ‘Available Options’ drop down list and select ‘Show hidden and backup files’ and press the ‘Add’ button. This should include all hidden files in your search.

To see a list of the hidden directories in your home folder, open the shell and type the following:

ls -a

By default, your command prompt should open in your home folder. So you shouldn’t need to navigate to ‘/home/user_name/’.