Let’s first compare garbage collection to a real world example: garbage collection! In real world you don’t go to the garbage dump every time you are done with a piece of paper, instead you keep them in a small bin under your desk, then when the bin is full you dump it all at once; obviously more efficient than cleaning your garbage after every operation. But is this really how garbage collection works in modern programming languages? Almost, except that they keep the garbage on the desk, mixed with needed papers! As long as there is empty space on the desk we dont need to perform garbage collection. This could be more efficient if you are very busy and you know your task will be quite short after which you can dump the whole thing, like in a web server, but not if you are a regular user because, first, your desk will look messy 99% of the time, second, you will need more time to start any task since you will need to perform some cleaning at the beginning of each. Maybe this is why Windows always seems to be low in memory and usually takes a considerable amount of time to launch an app even if the app looks so small!

Microsoft came up with the slogan: unused memory is wasted memory, and unfortunately a lot of people have fallen into this. Really, how does filling your memory with garbage make it not wasted?! When a user buys an additional memory we should assume his intention is to fill it with data, not to give it to us to use as a garbage bin.

So what’s the solution? The solution is obviously to give the programmer more control, and more responsibility. A balance between the completely manual allocation process of C and the completely automated process of garbage collection can save the user a lot of wasted memory and a lot of unneeded memory defragmentation. Yes, it will be a bit more work on the programmer, but I think it will be a good balance between code efficiency and implementation efficiency.

Underscore naming convention uses all lower case words, and separate them with underscores. The common is to use this for variable and function names, and to use Pascal convention for classes, structures, enumerations, and interfaces. Underscores were used by C programmers, then C++ adopted the same convention for its keywords and Standard Templates Library, and later on Boost used the same convention, making this convention quite popular among C++ programmers, but not dominant as other programmers used various other conventions including Pascal and camel case conventions. Underscore convention is also used by PHP’s standard libraries and is pretty much the standard for PHP developers. Ruby also uses underscores, or so I heard.

On the other hand, camel case naming convention is mostly known to be the standard for Java and its little sister JavaScript, although you can find it in use in various other places. Camel case simply starts each word with an uppercase letter, except for the first word which remains in lower case. The words are not separated by any underscore, obviously. Like in the underscore convention, this applies mainly to variables and functions, while type names (classes, structures, interfaces, enumerations) remain in Pascal convention. C# uses a variation of this convention by limiting the camelcase to function parameters and local variables.

Of course each of the two conventions has its own strengths and weaknesses. The following list summarizes the strengths and weaknesses of the two:

• Underscores make phrases easier to read. Compare the underscore_naming_convention to the camelCaseNamingConvention.
• Camel case makes paragraphs easier to read! Of course, when you read code what’s important for you is to understand the overall operation or algorithm, not the words in a phrase. Compare the following:
  my_first_variable=my_second_variable-my_third_variable;
  to this:
  myFirstVariable=mySecondVariable-myThirdVariable;
  Obviously in this case the camel case is easier to read. From the first glance you realize it’s a subtraction between two variables, while in the case of underscores you need to concentrate before you realize where the minus sign is. You may even mistake it for being one long variable instead of two. This is a strong disadvantage for the underscore convention, however, coloring can solve this problem if the editor gives identifiers a different color from operators, but that’s dependent on the editor.
• Camel case is the negative of English. In english, the first word in a sentence starts with an upper case and the rest remains in lower case. This is probably true for many other human languages. Camel case is the exact opposite. This is mind itching indeed.
• Underscores are harder to type. Even with the availability of intellisense, you still need to type the underscore in many cases.
• Camel case is not consistent because with constants (which is all in upper case) you still need the underscores. On the other hand, the underscore convention CAN be consistent (if you decide to use underscores even for type names, which is doable, i.e. My_Type instead of MyType).

Any more pros and cons you can think of? Please let us know.

Few weeks ago I was working on a medical application for managing diabetes clinics and their patients. The application is a big system that manages everything related to a diabetes clinic, but one part of it is intended to track patients’ statuses. The idea is to allow patients to use their personal glucose meters to submit their blood glucose data from home. The system will then monitor the records of all patients and when a specific patient goes into the red zone the medical staff is informed immediately. Sounds like a great idea, but how do we allow the patient to upload their glucose data? The logical answer is to let them connect their devices to the serial port and have our application read that serial port. For a desktop application this is a straight forward task, but we are living in the web age where everything is going online and people are less willing to download applications locally. I was using .NET and I thought of using client-side managed code for this task, which will work if the user is an administrator. Note that by administrator I don’t mean a Windows user account with Administrator priveledges; I mean a person who has the knowledge of a system administrator in order to go into the .NET security configurations and give access rights to my code. Without the correct access rights given the code will simply error out, the user will not even know what was wrong, not to mention giving him/her the ability to allow or deny the code from running, which is what logically should happen. There is no way for us to ask the user for permission, the only solution is to have the user give the required access rights (which 99% of users don’t know how to do), or to have the user install something on their machine. This was using .NET, and Microsoft is always being accused of having loose security models, so I guess I can bet that other vendors have similar tight security settings.

Security enthusiasts will probably flame me for complaining and tell me there are ways around this, which is true, but should we design our needs around an existing security model? Shouldn’t it be that the security model is designed around our needs? So how should the system’s security behave then? Maybe ask the user for permission at the time a permission is needed? I don’t really know how the ultimate solution should look like; all I know is that in order to protect the user’s data I was prevented from protecting his life, literally!

We are going to expand the Controller class with functionalities needed for handling PDF views. Our new class will be called MyController and it will inherit from MVC’s Controller. Any controller that needs to support PDF views will need to inherit from MyController instead of Controller. As you know, the Controller class has a method called ‘View’ which performs all that’s needed to be done for an HTML view to be rendered to the browser. Following a similar approach, we are going to create a new method called ‘ViewPdf’ that will send out a PDF file instead of an HTML file. But before we write that method, we’ll need to be able to render our views into a string instead of the browser. To do this we need to create a fake HttpResponse and give it a memory stream to write to. Then we’ll need to create a fake HttpContext to use that fake response. Then we can call ExecuteResult on our ActionResult object giving it the fake context. This will cause the view to be rendered to our memory stream. These steps will be included in a new method called RenderActionResultToString. This method will later on be used by ViewPdf to generate the PDF data.

protected string RenderActionResultToString(ActionResult result)
{
    // Create memory writer.
    var sb = new StringBuilder();
    var memWriter = new StringWriter(sb);

    // Create fake http context to render the view.
    var fakeResponse = new HttpResponse(memWriter);
    var fakeContext = new HttpContext(System.Web.HttpContext.Current.Request,
        fakeResponse);
    var fakeControllerContext = new ControllerContext(
        new HttpContextWrapper(fakeContext),
        this.ControllerContext.RouteData,
        this.ControllerContext.Controller);
    var oldContext = System.Web.HttpContext.Current;
    System.Web.HttpContext.Current = fakeContext;

    // Render the view.
    result.ExecuteResult(fakeControllerContext);

    // Restore old context.
    System.Web.HttpContext.Current = oldContext;

    // Flush memory and return output.
    memWriter.Flush();
    return sb.ToString();
}

Now that we can intercept our rendered views as strings, we can now convert them into PDF files. This will be done inside the ViewPdf method, which returns an ActionResult object, so it can be used in the controller the same way the View method is used. ViewPdf creates a memory stream to which the generated PDF will be written, then it gets the buffer from that memory stream and uses it to initialize the BinaryContentResult object that will be returned to the caller.

        protected ActionResult ViewPdf(object model)
        {
            // Create the iTextSharp document.
            Document doc = new Document();
            // Set the document to write to memory.
            MemoryStream memStream = new MemoryStream();
            PdfWriter writer = PdfWriter.GetInstance(doc, memStream);
            writer.CloseStream = false;
            doc.Open();

            // Render the view xml to a string, then parse that string into an XML dom.
            string xmltext = this.RenderActionResultToString(this.View(model));
            XmlDocument xmldoc = new XmlDocument();
            xmldoc.InnerXml = xmltext.Trim();

            // Parse the XML into the iTextSharp document.
            ITextHandler textHandler = new ITextHandler(doc);
            textHandler.Parse(xmldoc);

            // Close and get the resulted binary data.
            doc.Close();
            byte[] buf = new byte[memStream.Position];
            memStream.Position = 0;
            memStream.Read(buf, 0, buf.Length);

            // Send the binary data to the browser.
            return new BinaryContentResult(buf, “application/pdf”);
        }

That’s all that’s needed in our MyController class, but what’s the BinaryContentResult class used inside the ViewPdf method? It’s a class inherited from ActionResult that is used to return arbitrary content, much like the ContentResult class, but returns binary data instead.

    public class BinaryContentResult : ActionResult
    {
        private string ContentType;
        private byte[] ContentBytes;

        public BinaryContentResult(byte[] contentBytes, string contentType)
        {
            this.ContentBytes = contentBytes;
            this.ContentType = contentType;
        }

        public override void ExecuteResult(ControllerContext context)
        {
            var response = context.HttpContext.Response;
            response.Clear();
            response.Cache.SetCacheability(HttpCacheability.NoCache);
            response.ContentType = this.ContentType;

            var stream = new MemoryStream(this.ContentBytes);
            stream.WriteTo(response.OutputStream);
            stream.Dispose();
        }
    }

We are now ready to start writing PDF views. The following example shows a simple PDF view that renders the list of orders for a specific customer.

<%@ Page Language=”C#” Inherits=”System.Web.Mvc.ViewPage<Sample1.Models.Customer>” %>
<%@ Import Namespace=”Sample1.Models” %>

<?xml version=”1.0″ encoding=”UTF-8″ ?>
<itext creationdate=”2/4/2003 5:49:07 PM” producer=”iTextSharpXML”>
 <paragraph leading=”18.0″ font=”unknown” size=”16.0″ align=”Default”>
     <chunk>Orders in PDF</chunk>
 </paragraph>
 <paragraph leading=”18.0″ font=”unknown” size=”10.0″ align=”Default”>
  <chunk>Customer Name: <%= this.Model.Name %></chunk><newline />
  <chunk>Address: <%= this.Model.Address %></chunk><newline />
 </paragraph>
 <paragraph leading=”18.0″ font=”unknown” size=”10.0″ align=”Default”>
 <chunk font=”unknown” size=”12.0″>Orders:</chunk><newline />
 <% foreach (Order o in this.Model.Order)
       { %>
        <chunk font=”unknown” size=”10.0″><%= o.OrderId %>, <%= o.Description %>, <%= o.Amount %>, <%= o.Date %></chunk><newline />
 <% } %>
 </paragraph>
</itext>

We’ll name the view OrdersInPdf and our controller will then look like this:

    public class HomeController : MyController
    {
        private Sample1Entities entities = new Sample1Entities();

        public ActionResult OrdersInHtml()
        {
            Customer c = (
                from cust in entities.Customer
                where cust.CustomerId == 1
                select cust).First();
            c.Order.Load();
            return View(c);
        }

        public ActionResult OrdersInPdf()
        {
            Customer c = (
                from cust in entities.Customer
                where cust.CustomerId == 1
                select cust).First();
            c.Order.Load();
            // To render a PDF instead of an HTML, all we need to do is call ViewPdf
            // instead of View. This requires the controller to be inherited from
            // MyController instead of MVC’s Controller.
            return ViewPdf(c);
        }
    }

As the code implies, OrdersInHtml will render an HTML view which is the default behaviour of MVC, while OrdersInPdf will render a PDF instead. Notice that the only difference between the two is the return statement, OrdersInPdf calls ViewPdf instead of View. The programmer needs to make sure when he calls ViewPdf that the view contains iTextSharp XML data rather than HTML data. The other thing to notice in the controller is the first line which shows that the controller inherits from MyController instead of Controller.

iTextSharp also has the ability to convert HTML into PDF so we can modify the ViewPdf (or create a new method) to make it parse HTML instead of XML. However, it’s usually hard to get the expected formatting when you convert from HTML.

Download Sample

License
This article and the included code is licensed under The Code Project Open License (CPOL).