Monday, May 28, 2007

From time to time I have to create a form that is used both for display and input of data (or in other words for viewing or adding/editing). As an example, imagine a form for entering customer data. The form will include fields such as Name, Address etc. There are few possible solutions to this problem.

First and most easy to implement is to create a single form, put required input controls on it: one TextBox for Name and one for Address. When constructing the page on the server, we have to check if the form is used  in View mode in which case we have to set the controls' ReadOnly property to true. Otherwise we can leave it as false. ASP.NET controls mostly support this kind of mechanism. The problem is that a ReadOnly TextBox is still rendered as HTML input control. You can try to hide the fact by using CSS styles, but underneath it is still an input control for a form that does not require one.

Another solution I have seen used a lot is to create a separate page used only to display the date and another page for editing/adding data. In this case, the page used to display data uses controls such as Label control so no input field is generated. The other page works as can be expected. The problem with this solution is that now we have two pages and some of the logic/layout/whatever is duplicated.

ASP.NET architecture to the rescue! Since ASP.NET is designed in such a way that it makes heavy use of controls, we can take advantage of the fact and introduce a special kind of TextBox control that is intelligent in a way it renders itself.

The way to achieve this goal is simple. Create a new Class, make it inherit from the TextBox control and override few methods:

public class TextBox : System.Web.UI.WebControls.TextBox
{
    [DefaultValue(false)]
    public bool RenderReadOnlyAsText
    {
        get { return (bool)(ViewState["RenderReadOnlyAsText"] ?? false); }
        set { ViewState["RenderReadOnlyAsText"] = value; }
    }
    protected override void AddAttributesToRender(System.Web.UI.HtmlTextWriter writer)
    {
        if ((!RenderReadOnlyAsText) || (!ReadOnly))
        {
            base.AddAttributesToRender(writer);
        }
    }
    protected override void Render(System.Web.UI.HtmlTextWriter writer)
    {
        if ((RenderReadOnlyAsText) && (ReadOnly))
        {
            System.Web.UI.WebControls.WebControl span = 
            new System.Web.UI.WebControls.WebControl(System.Web.UI.HtmlTextWriterTag.Span); span.RenderBeginTag(writer); writer.Write(Text.Replace(Environment.NewLine, "<br />")); span.RenderEndTag(writer); } else { base.Render(writer); } } }

Notice the RenderReadOnlyAsText property which is false by default making the new control behave just like a normal TextBox. Next we need to override the Render method. I have used span control to replace the normal input control, but feel free to experiment. The thing to remember is to replace the NewLine characters with HTML line breaks (probably some CSS style would also do). Additionally I have overridden the AddAttributesToRender method so that it does not add any attribute to the control in case it is rendered as a plain text (or span in my case).

Using this control on a page is simple. Just set the RenderReadOnlyAsText to true and set ReadOnly property to true when necessary.

kick it on DotNetKicks.com

Monday, May 28, 2007 4:34:05 PM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
 Monday, May 14, 2007

I've been playing with ASP.NET Localization features lately and I have mixed feelings about it. I mean, the Localization features of ASP.NET are great, but you have to be very careful not to mess up.

Visual Studio 2005 allows for easy localization of a page or a control via the Tools->Generate Local Resource menu item. I have tried this one on the source view of the page (the view that I most often work with). The problem is that it does not work from this view!!! The error message is:

---------------------------
Microsoft Visual Studio
---------------------------
Source view does not support resource generation. Switch to design view to generate resources.
---------------------------
OK
---------------------------

Ooook. I thought that we have to separate presentation from logic but I suppose this is an exception from the rule. No wonder it was so hard to remove "the feature" of reformating the code after switching from source view to design view in Visual Studio 2003 if they have a code with such high quality. There is simply no separation between the model and the view so problems are to be expected.

So I have switched to the design view and on my sample page, with only a GridView with few collumns, everything worked fine. I've got the App_LocalResources folder and a Default.aspx.resx file in it and every localizable property was already in there. The aspx markup was also modified - meta:resourcekey attributes have been added to all relevant places. Nice? Not so, unfortunately :-(.

I have tried the same technique on a real page from a real project. On the page, there were a couple of my custom controls. Invoking the Generate Local Resource function on such a page made a lot of mess with the html/aspx code. Some controls have been added as inner controls etc. This is probably the very reason why cybercrypt15/glenn writes that you should not use the Generate Local Resource feature.

If you do all the work manually (wich is not such a big task after all - just add a meta:resourcekey attribute where necessary), you will find that Localization is really a nice feature.

kick it on DotNetKicks.com

Monday, May 14, 2007 9:40:29 AM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
 Friday, May 11, 2007

For a long time now I have been working with only one monitor. For a developer it poses some difficulties like lots of overlapping windows. Without even really knowing how it is really like I have always been an advocate of a dual monitor setup. Now when I have a laptop and an external LCD I can only say that I was right, but at the same time wrong!

Two monitors give you much more space on which you can put your windows. For instance you can put a help window on one monitor and the code on the other. If you work with ASP.NET you can have a browser running on one of the monitors while you edit the code on the other and take advantage of Edit and Reload feature. Possibilities are almost countless. Almost...

The one thing that I was wrong about is the fact that my primary development tool: Visual Studio 2005 does not support dual monitor setup! Can you imagine? The only support available is that you can move SOME of the windows on to the second monitor. The windows you can move include Solution Explorer, Watch, Immediate and all the other dockable windows. Good as it is, I think it is only a side effect of those windows being draggable. The problem is that Visual Studio was never intended to be used on more than one monitor and that is why you cannot move the most important windows to the second monitor. What are the most important windows? For me it is the code window and the design window (ASP.NET).

At first I thought that I might be missing something. Some switch in the preferences. Unfortunately it is simply impossible according to the following sources:
http://blogs.msdn.com/saraford/archive/2005/07/20/441126.aspx
http://blogs.msdn.com/saraford/archive/2004/05/18/134295.aspx

That's a pity. I cannot wait for the next version of Visual Studio in hope that they will add the support for more than one monitor.

Friday, May 11, 2007 2:10:31 PM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [2]  | 

ASP.NET comes with a set of controls called "Validation Controls". Useful as they are, there are few features missing to make the picture complete. Some of the shortcomings have been fixed with the ASP.NET 2.0. This includes the ValidationGroup property. Some of the missing features I have described in my other articles: Validation Controls As Images - Take 2, Validation Control As Images - Workaround and Validation Controls Vs Control Adapters.

One thing that I have recently discovered missing from the set of features ASP.NET validation infrastructure provides was the way to perform initial validation of a page right after it has been downloaded by the browser for the first time. Imagine for example a form on a page where you instantly know which fields are required. Normally to do it, you would emphasize the labels of those fields in some way - probably by using a stronger/bigger font. I like not to repeat myself so I've tried to use the Validation Controls just for this. Instead of a bold label I wanted to have an ErrorMessage of each ValidationControl displayed for each field that requires validation.

After a bit of searching I have found no solution to my problem so, as usual, I have used my old mantra: "use the source Luk". What I have found is that it should be possible to do it so after few failed approaches I have found the way.

In order to perform initial validation on an ASP.NET page I have used a following JavaScript function:

function initialValidation()
{
    if (typeof(Page_Validators) == "undefined")
    {
        return true;
    }
    var i;
    for (i = 0; i < Page_Validators.length; i++)
    {
        ValidatorValidate(Page_Validators[i], "", null);
    }
}

I have put the call to this function in a body.onload event of an HTML page (the only place that I have found it to work).

The interesting thing is that if you are using ValidationSummary to display a summary of all errors on a page, it will not be shown after the initial validation. It will be shown if a user despite having the error message displayed near the input, tries to submit the page.

As a side note: don't forget to validate everything on the server-side! Do not trust the data that comes from the user!

kick it on DotNetKicks.com

Friday, May 11, 2007 1:58:04 PM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [1]  |