Tuesday, August 08, 2006

Since I have first seen Db4o database it has became my database of choice for every personal project that I do. You can read more about this database on its home page and I strongly recommend you to do so, even if you are not planning to leave the relational world. Reading about object databases will broaden your horizons and maybe it will change the way you implement your applications as it changed mine.

Tuesday, August 08, 2006 8:09:01 PM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 

In the first article about optimizing rendered page size I have pointed out that you should consider using short names for content placeholders on your master pages because each control's id inside those placeholders is prefixed with the id of the placeholder. But when you look inside the page there is of course another field where you can make some improvements - the ViewState.

There are lot of articles about what you can do to make the ViewState smaller. Mainly - disable it everywhere where it isn't needed. This is a first step you can take. Amongst other things you can also use the SavePageStateToPersistenceMedium and LoadPageStateFromPersistenceMedium methods of the Page class. The purpose of those methods according to MSDN is to save and load any view state information from and to a page object. And that is true. But how to use those methods?

Browsing the results returned by google you can find plenty of solutions out there each unique in its way. Why they are different? The problem with those methods is not saving the state. To save the state you can use anything from the Session object, flat files or even database. The real problem is making sure that when a form is submited to a server, its ViewState is properly loaded - the concrete ViewState that was saved for that concrete page. A solution to just use Session["ViewState"] as a storage medium won't do, because then we can only have one ViewState for each user - no multiple windows/frames allowed.

My solution would be to include a hidden field on each page, name it somehow and use its value as a key for identifying which ViewState to load. Such a hidden field may be added dynamicaly in a base page so no additional work is required when adding new pages to a project. This field of course shoud hold some unique value (such as guid) in order to distinguish one page request from the other.

kick it on DotNetKicks.com

Tuesday, August 08, 2006 7:41:13 PM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [2]  | 

I'm in process of creating one web site on which I needed a checkbox but I needed it to de displayed in form of an image. So I went to google and performed a search for a ready to use control. What I have found was not satisfying at all so I have created my own and the result is available within my controls pack as along with some other controls here.

Tuesday, August 08, 2006 2:05:25 PM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 

I have created an ASP.NET controls pack that I'm using on a daily basis. The pack includes:

Control Name Description
Button A Button that supports a Confirmation message before submitting a form.
Image An Image that allows you to set the MouseOverImageUrl property.
ImageButton An ImageButton that supports a Confirmation message before submitting a form and a MouseOverImageUrl.
ImageCheckBox A CheckBox that renders itself as an image either checked or unchecked. It also supports MouseOverImageUrl for both states.
MyObjectDataSource An ObjectDataSource that supports build in sorting and filtering of returned objects.
CompareValidator A CompareValidator that supports displaying error messages as an image.
RequiredFieldValidator A RequiredFieldValidator that supports displaying error messages as an image.
PageParameter A parameter that can be used in DataSource controls parameter collections such as SelectParameters. It allows you to get parameters from properties of a page.
TemplateControlParameter A parameter that can be used in DataSource controls parameter collections such as SelectParameters. It allows you to get parameters from properties of a nearest TemplateControl.

I find those control very helpful on a daily basis and hope you will like it also. Note also that some of them I have described earlier but now I provide them as a one download with a full source code. It is available here: Controls.zip (50.7 KB).

Using most of the controls should be obvious. The most complicated one is the MyObjectDataSource. Mostly I have described it in my previous articles about this control. I have added a filtering feature by specifying FilterParameters on the data source control. There are two options: you can either use the internal filter mechanism which will filter values for you or by providing an additional parameter to a select method that is used for selecting objects. This additional parameter should be of type Dictionary<string, object> where the key is the name of the property to filter. Working with internal filter requires almost no code for example using ControlParameter:

<asp:ControlParameter Name="Role.Id" ControlID="Role" PropertyName="SelectedValue" />

Where Name attribute corresponds to a name of the property by which you want to filter and PropertyName corresponds to a property on a control that provides a value to filter by. (I know it my not be very intuitive, but that is what ASP.NET provides and I have been building on top of that). Filtering currently works similar to SQL LIKE command with wildcards before and after the expression.

If you work without internal filter you have the responsibility to filter the collection yourself given the filter parameter to passed to a select method.

kick it on DotNetKicks.com

Tuesday, August 08, 2006 12:06:14 PM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [1]  | 
 Monday, August 07, 2006

So after two days of configuration and moving my articles from my old blog I finally have my new blog set up :-). I'm still to create my own template, but for now the standard one will have to suffice.

Monday, August 07, 2006 6:55:15 PM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 

I haven't played with it a lot but but the most obvious was the far from complete support from the IDE. Given it is not a complete product I'm not blaming MS for it. What I blame MS for is the fact that installing LINQ is a destructive process i.e.: it damages some of the existing features of VS 2005.

For me the One thing that hurt the most was the fact that the refactoring SmartTags stopped working from a keyboard shortcut and that the Refactor option was missing from the context menu of the code window.

Since I could not imagine working without some useful shortcuts I started the process to recover the lost features. I've tried to reset the shortcuts from Tools-Options-General-Keyboard menu but it had no effect. Next I have tried to reset all settings using Tools-Import and Export Settings - no effect. Next there came Google.

I have found and that someone had a similar problem and there was a solution. Few posts from the top there is a 4 steps instruction (which didn't work for me) and than a 5th step which finally worked. I'm putting the stepps I have followed in for your convenience:

  1. Start up RegEdit.exe
  2. Open HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\8.0\Packages\{A066E284-DCAB-11D2-B551-00C04F68D4DB}\SatelliteDLL
  3. Edit the "Path" value and change it from "C:\Program Files\Microsoft Visual Studio 8\VC#\VCSPackages\1033\" to "C:\Program Files\Microsoft Visual Studio 8\VC#\VCSPackages\"
  4. Restart Visual Studio and see if these problems are fixed?
  5. Go to C:\Program Files\Microsoft Visual Studio 8\Common7\IDE and run devenv /setup followed by devenv /resetuserdata followed by devenv /resetsettings CSharp.

All this stuff makes me wonder. I have been using beta software since I have learned using computers but I cannot remember having this kind of problems. Maybe the betas I use are not as complicated as Microsoft products but hey! They are not developed by the army of developers!

kick it on DotNetKicks.com

Monday, August 07, 2006 10:12:55 AM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 

All of us who have been using any kind of ASP.NET Templated Controls such as FormView, sooner or later come to a problem of extracting value from a field inside a template. For example when you are using a FormView control and want to programatically access a control inside one of the templates. What are the options? You have to resort to some kind of FindControl calls which are way from perfect. I have been thinking about this issue for some time now and I have an idea.

The idea is to change tha way the PageBuildProvider constructs the part of class that represents the ASPX file of your page. (the other one is of course the code behind). So what could be changed? Imagine a situation where you have a page and there is just one FormView on it. The FormView has its templates defined in an ASPX file. What happens now is the ASP.NET framework builds the part of the class given this ASPX file and what we get is a nice intellisense in the code behind telling us that the our class has a field FormView1 of type FormView which of course does not have any knowledge about controls inside the templates. But what if...

But what if instead of the FormView1 being of type FormView, the part of the class constructed from ASPX file provided us with a field FormView1 of type derived from the FormView but with few additional properties which represent controls found inside the templates - in a strongly typed manner.

Now. The benefits of such a solution are obvious mainly compile time type checking.

Is it possible to make ASP.NET 2.0 to provide such a solution? This is a hard question. I have checked the major components that are responsible for the way the classes are constructed now. I haven't gone deep into details but it it looks like some changes inside the PageBuildProvider (or some base classes) would be required. Also a ControlBuilder responsible for building a templated control would have to constuct a whole new class representing our control. I suppose that the major problem lies in constructing such a derived class with all those properties representing inner controls.

So basically I hope MS will/is thinking about making our lives easier and more type safe :-) or maybe some brave developer is willing to try to implement my concept? Either way it would be nice to have such a feature some time in the future.

Some additional considerations include the problem with accessing controls from ItemTemplate of a FormView control when in Edit mode. Another issou would be with controls such as GridView where some of the templates represent a repeating content and not a single data etc...

kick it on DotNetKicks.com

Monday, August 07, 2006 10:11:13 AM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 

I have written few times about the little known features of variuos products etc. Today I will add one more to the list. There is a little known feature that web browsers have that can be very useful...

The feature I'm talking about is the possibility to execute simple (or even complex) Javascript code from the address bar. While reading this go ahead and type something like:

javascript: alert(2+2);

in your brwoser's address bar and hit enter. You will see a messagebox containing the result of the expression passed as the argument to the altert function. A simple calculator, but you can go and create more complex scripts such as scripts modifying some DOM elements.

Here is a script that I sometimes use to get the current DOM of the page - after it has been modified by any user actions/javascripts such as AJAX calls.

javascript: var x = window.open(); x.document.write(document.childNodes[1].innerHTML.replace(new RegExp(/</g), "&lt;").replace(new RegExp(/>/g), "&gt;"))

If the page you are trying to view does not have the DOCTYPE declaration just change the document.childNodes[1] to document.childNodes[0]. I have tested this with IE 6.0 and it seems to work well. For FireFox users there are a lots of plugins available to do the same thing.

kick it on DotNetKicks.com

Monday, August 07, 2006 10:10:05 AM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 

ASP.NET 2.0 comes with a mechanism called two way databinding which allows us to declaratively bind a form element to a property of an object in such way that updates are supported. For the readonly display you typically use the Eval method in your aspx page. For the two way mechanism, you use the Bind keyword (or method?).

Using the Bind keyword is really simple in most scenarios that you encounter, especially if you are using the SqlDataSource control. Problems start to come up when you try to use a more object oriented approach and use the ObjectDataSource control.

Now, still in most cases using ObjectDataSource will not cause you any problems when what u bind is a simple property such as a name of a client i.e.: you have a collection of clients that you bind to a GridView and one of the columns displays the name of the client. To do so you use something like Bind("Name"). The problem arises when you need to bind to a subproperty such as in Bind("Address.StreetName"). This won't work unfortunatelly...

Why it is not possible to perform a two way databinding in such a way, there are discussions over the Internet. BTW: Eval("Address.StreetName") works as expected. So what can we do about it? Of course there is a solution for this problem and it has came to me when I was thinking why there is no such a problem when you use the SqlDataSource control.

The reason why there is no such problem when you are working with relational data is that you are creating an SQL query that is a VIEW of the data that you want to display i.e.: it has all the columns you need and there are no "sub-columns". So what we need to do is to translate this to an object world.

So basically what we need to do is create an object that will serv as a view on our objects and bind to this view object. For example given the aforementioned client object with a name and an address we create a ClientView object that encapsulates our client object and exposes the needed properties such as Name or StreetName. Those properties in turn call on the properties of the client object either directly as in Name or to some nested property as in Address.StreetName.

Making a select method used by the DataSourceControl to return the collection of ClientView object should not pose any problem. When using such a technique I would suggest putting the view classes somewhere outside the domain model since the only reason they exist is to allow for the two way databinding to work so there is no reason to pollute the model.

kick it on DotNetKicks.com

Monday, August 07, 2006 10:08:44 AM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 

Sometimes you really need to debug some part of the application but you don't want to start it. For example you want to debug some lower layer of the application and the startup time takes too long. There is a quick solution for this problem. You can use the Immediate Window from Visual Studio to start a debug session. Just type a class name (with namespace) and a method name you want to call if it is static. Otherwise you have to add a call to constructor in a form of "new" keyword. Just remember to put a breakpoint somewhere :-)

As far as I know this window is not available by default so use Debug/Widnows/Immediate to show it.

The sad thing is that it does not work for an ASP.NET project, but other than that you can use it not only for testing your own methods, but to call methods of the built in classes such as System.DateTime.Now.

Monday, August 07, 2006 10:07:58 AM (Central European Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [2]  |