gljakal.com – blog

When designing websites, I usually write multiple stylesheets for multiple parts of the website. For example, for gljakal.com I had 5 different stylesheets:

1. header.css for the header/logo area,
2. content.css for the content area,
3. sidebar.css for the sidebar,
4. footer.css for the footer
5. and finally theme.css, that includes the style for all the above:

   @import url("header.css");
   @import url("sidebars.css");
   @import url("content.css");
   @import url("footer.css");

On more complex projects, I usually have even more stylesheets. One thing I am usually constant about however is having a generic theme.css or style.css that includes the other files. This is convenient because in my HTML pages I just have to link only one stylesheet file.

This technique works really well when testing the website on my local machine, however in production it has the downside of generating multiple requests on the client.

To address this problem, I wrote a small command-line program that would follow @import instructions and merge the imported files in the main one. It’s called CssCombine.

The code (in c#) is merely 48 lines long:

using System;
using System.Collections.Generic;
using System.Text;
using System.Text.RegularExpressions;

namespace CssCombine
{
    class Program
    {
        static void Combine(string parFileName, StringBuilder parOutput)
        {
            string[] lines = System.IO.File.ReadAllLines(parFileName);
            foreach (string s in lines)
            {
                if (s.Trim() != "")
                {
                    Regex rgx = new Regex(@"@import\s+url\s*\((.*)\);", RegexOptions.IgnoreCase | RegexOptions.CultureInvariant);
                    string[] sx = rgx.Split(s);
                    if (sx.Length > 1)
                    {
                        string sFile = sx[1].Replace("\"", "").Replace("'", "");
                        sFile = System.IO.Path.Combine(System.IO.Path.GetDirectoryName(parFileName), sFile);
                        Combine(sFile, parOutput);
                    }
                    else
                    {
                        parOutput.AppendLine(s.Trim());
                    }
                }
            }
        }

        static void Main(string[] args)
        {
            if (args.Length != 2)
            {
                Console.WriteLine("Usage: CssCombine [input.css] [output.css]");
            }
            else
            {
                string input = args[0];
                string output = args[1];
                StringBuilder sbOutput = new StringBuilder();
                Combine(input, sbOutput);
                System.IO.File.WriteAllText(output, sbOutput.ToString());
            }
        }
    }
}

Or you can download the compiled program here.

Another optimization would be to minify the resulting file. I use Yahoo’s YUI Compressor for that.

In my previous article, Getting rid of the Naming Container in asp.net 2.0, I explained a method to override the extended naming functionality provided by ASP.net in order to create client-side controls with better IDs.

I was however informed in the comments that by overriding the NamingContainer property the control loses the ability to read its value from the PostBack data.

Since the controls I developed were not meant to to be used in a postback scenario, this wasn’t a big problem for me.

Fast-forward a couple of years and here I am, wondering why post back does not work in one of my projects 😉

Anyway, I looked at the link provided by Alex, where Rick Strahl talks about overriding the ClientId and the UniqueId properties instead of NamingContainer.

In a standard web control, the two properties ClientID and UniqueID are mapped, respectively, to the id and name properties of the HTML control generated.

Since most (all? ) JS frameworks use the id property to access the varius HTML elements and the PostBack mechanism uses the name property, I think the “best of both worlds” solution is to only override the ClientId:

public class NiceTextBox : System.Web.UI.WebControls.TextBox
{
    public bool UseNamingContainer { get; set; }
    
    public override string ClientID
    {
        get
        {
            if (this.UseNamingContainer)
                return base.ClientID;
            else
                return this.ID;
        }
    }
}

Now our NiceTextBox works even during post-back scenarios 🙂

Lately I’ve been playing around with asp.net 2.0.
One of the new “features” of asp.net 2 is the introduction of Naming containers.
While using naming containers can be really useful when using databound controls and standard asp.net coding, they can be a real pain to work with when making extensive use of javascript.
This is because a control declared as

<asp:TextBox ID="TextBox1" runat="server" />

will be rendered as

<input name="ctl00$ContentPlaceHolder1$TextBox1" type="text"
    id="ctl00_ContentPlaceHolder1_TextBox1" />

on the client side, thus breaking any script referencing TextBox1 with, for example, getElementById(‘TextBox1’).
This behavior is built inside asp.net and is triggered not only when using databoud controls (where it would be necessary to prevent having multiple controls with the same name, for example inside a datagrid), but it is also triggered when using Master Pages, where having multiple controls with the same name is almost impossible.
So, how do we code around it?

The client-side hack

Luke Foust, in his article Using JQuery to Make Asp.Net Play Nice with Asp.Net, explains a couple of client-side methods to let your javascripts select the right element in this situation. I recommend you to read it, because it contains some nice ideas and it also shows off some of the power of JQuery.
While these methods will work for most projects, they still present a couple of issues:

• Generally quite hard to mantain, especially the first hack
• Code bloat. While bandwidth is costantly becoming less of an issue, the generated page will have elements with horribly long declarations
• It breaks existing scripts. You’ll have to re-check and re-code most of the scripts that should already work
• Extra workload on the client. Todays PCs are fast, so this is less of an issue, however it is something you should consider if you have a lot of asp.net controls in your page.

The Solution

Let’s face it: the problem is really on the server, not on the client. Asp.net should not generate those horribly long IDs in the first place, unless we want to. So the best solution is a server-side hack.
How does asp.net know whether or not it should generate a unique id for our controls?
Every WebControl in asp.net exposes a property called (I’m sure you guessed it) NamingContainer, which tells asp.net what’s the parent control for our textboxes, labels and so on. All we have to do in our code is create a new class that will inherit the control we want to "sanitize" and hide that property from asp.net. Better said in code than in words:

using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;

namespace wtd
{

    /// 

    /// A TextBox control without ugly IDs
    /// 
    public class TextBox : System.Web.UI.WebControls.TextBox
    {
        public override Control NamingContainer
        {
            get
            {
                return null; 
            }
        }
    }

}

Then, in our pages, all we have to do is register our new set of controls, like this:

<%@ Register TagPrefix="wtd" Assembly="app_code"
     Namespace="wtd" %>

and replace every instance of the default asp controls with our own set of controls (a simple find&replace will do the trick), so

<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>

becomes:

<wtd:TextBox ID="TextBox1" runat="server"></wtd:TextBox>

And that’s it! Our textbox will now be rendered like this:

<input name="TextBox1" type="text" id="TextBox1" />

Not only this method won’t break your existing javascript, it also works nicely with your existing server-side code 🙂

Update

As pointed out by some of you in the comments, this method does not work in a traditional post-back scenario. See my new article for a possible solution to this problem.

If you’re getting an “unknown runtime error” in internet explorer while using the javascript method object.innerHTML=”…some html”, here is a hint to put you on the right track: you’re probabily trying to put a block-level element inside an inline element.
For example, given the html code:

<p id="the_container">Hello</p>

<script type="text/javascript">
<!--
var obj=document.getElementById('the_container');
try
{
obj.innerHTML='<ul><li>List item 1</li><li>List item 2</li></ul>'; 
}
catch(ex)
{
alert(ex.message);
}
//-->
</script>

In internet explorer, a dialog will pop up complaining about an “unknown run-time error” (Thanks Microsoft for your helpful error messages). The solution (if you really can’t force your users to use Firefox :)) is to sobstitute the parent element with a block-level one, such as a DIV:

<div id="the_container2">Hello</div>
<script type="text/javascript">
<!--
var obj=document.getElementById('the_container2');
try
{
obj.innerHTML='<ul><li>List item 1</li><li>List item 2</li></ul>';
}
catch(ex)
{
alert(ex.message); // never displayed
}
//-->
</script>

Choosing a good web hosting provider should always involve a bit of research (unless you like to throw your money out of the window, in which case you could always give some to me 🙂 ). There are a lot of parameters you should check before selling your soul choosing your hosting company. Here are some of them…

• The server’s operating system That’s an easy choice, choose a Windows-based server if you intend to build your website using ASP or ASP.net, or choose a Linux for everything else.
• The scripting language support That’s another easy one. What do you want to use for your website? ASP? ASP.net? php? perl? Ruby on rails? Do you need a particular script? Choose the hosting companies that give you what you want, and ditch the others.
• The monthly bandwidth This is probably the most undervalued feature when choosing a web hosting plan. The term bandwidth refers to the amount of data your account can transfer in a month. That means that, for example, if your site consist of a single 100Kilobytes page and it gets viewed 100.000 times in a month, your account is consuming 100Kx100.000=10.000.000K, which is more or less 9.7 gigabytes in a month. It all depends on how many visitors your site gets and on the type of content you intend to publish. My advice is to stay away from companies claiming to give you “unlimited bandwidth”: there is no such thing as unlimited bandwidth, and it will often mean that if your website gets too many visitors, it will get randomly suspended or will get as slow as hell.
• The disk space explains itself: How much space does your site need? how much do you think it will grow in the next two years? More space is better, but in most cases you won’t even need all the space offered by the hosting plan.
• The domain name Of course you will need a domain name for your website. Does your hosting plan give you a free domain name? If yes, who will be the owner of the domain name? You or them? Keep in mind that you can always register a .com with godaddy for just $9/year.
• Database resources This single parameter can mean everything or nothing, depending on how your site is done. Do you need to use a blog? a CMS? do you use any script that needs database access? Unlimited databases are, of course, better than being limited to just one or two, but with a little of manual labor, you can always use the same database with more scripts.
• E-mail Any serious hosting provider will give your account some email capability. How many addresses do you need? Do they give you autoforwarders, mailing lists, autoresponders, and a catch-all address?
• Uptime is another very important parameter. It indicates the probability a visitor has to find your site actually running. 99% uptime is simply not enough for any serious need, because it means that statistically you’ll lose a visitor every 100. Keeping in mind that 100% uptime is impossible, choose a company that gives you 99.9% (lose a visitor every 1000) uptime or more.
• Speed You should always check the host’s speed (with a fast connection of course). How fast is the the hosting company’s website? How fast are their customers’ websites?
• Raw log files Does your hosting plan give you access to raw log files? Raw log files are text files monitoring every single access to your website, and are very important for any kind of statistical analysis you want to do, in order to know better who your visitors are and what are they looking for.
• The company’s reputation You have to choose a company you can trust. Once you have narrowed down the few companies that give you what you need, you should search for any complaints you can find on google. Be careful to weight them right however, there’s quite some difference between a forum user saying that the host xxx sucks and someone who took the time to create a website named “hostxxxsucks.com” to tell his horror story with that company. If you’re still in doubt, you can always ask to the people at webhostingtalk.com.

My search for a good web hosting company finally ended when I found LunarPages, wich is now giving away the basic plan (400GB bandwidth, 5GB HDD space, unlimited mysql databases, unlimited subdomains) for $6.95/month.
Ok, that’s it for this entry. Please leave a comment if you have anything to add, or just to say hi :), I’ll be sure to read them all.