BeFruit

WCF error: "This collection already contains an address with scheme http"

2008-09-08T16:00:00.004+02:00

I met this error, and wondered what this could be. The explanation is that "WCF services hosted in IIS can have only one Base Address", meaning that in IIS the website hosting the service can not be associated to http://www.example.com and http://example.com at the same time.

I don't know why this prevents a service to work, but I know this is annoying.
I found a couple of bloggers like Rob suggesting a solution with a coded custom ServiceHostFactory, which sounds terribly complicated to me as a workaround.

Fortunately there is a much simpler solution, just by touching the web.config file. Just add the following lines in the system.serviceModel section:
<serviceHostingEnvironment>

    <baseAddressPrefixFilters>

        <add prefix="http://www.example.com"/>

    </baseAddressPrefixFilters>

</serviceHostingEnvironment>
to only keep the service address.

Clone objects in C#

2008-07-22T21:33:00.007+02:00

It is simple to clone objects (i.e. make an exact copy of an object) that implement the IClonable interface. It has the Clone() method that you just have to call.

When the method is not available and the class is serializable (has the Serializable attribute), it is possible to use this feature. There are some examples over the Internet, here is a variant I adapted as a templated method:

private static T Clone<T>(T original)
{
BinaryFormatter bf = new BinaryFormatter();
MemoryStream ms = new MemoryStream();
bf.Serialize(ms, original);
ms.Flush();
ms.Position = 0;
return (T)bf.Deserialize(ms);
}

You call it this way:

MyClass copy = Clone<MyClass>(original);

But what to do with a non serializable object? The only way is to use reflection. Here is a simplified but working example. One should take care of readable and writable properties.

private static T Clone<T>(T original)
{
T copy = (T)(typeof(T).GetConstructor(System.Type.EmptyTypes).Invoke(null));
foreach (PropertyInfo pi in typeof(T).GetProperties())
{
object originalValue = pi.GetValue(original, null);
pi.SetValue(copy, originalValue, null);
}
return copy;
}

Corrupted applicationHost.config file in IIS 7

2008-05-30T11:49:00.001+02:00

IIS7 stores its parameters in an XML file, located typically at C:\Windows\System32\inetsrv\config\applicationHost.config. This is a nice solution as every parameter is clearly readable. Unfortunately, there are still some bugs (maybe in IIS 7, but some problems with anti virus programs have also been reported) and this file may be corrupted.
What to do when this file is truncated? Reset it and loose all of your settings?
Luckily IIS makes a backup each time you make a change. All those versions are stored in the folder C:\inetpub\history\. All you have to do is to copy a former applicationHost.config file into the C:\Windows\System32\inetsrv\config\ working directory.

WPF is all about Panels

2008-05-07T00:13:00.006+02:00

Have you noticed how most applications' windows behave badly when it comes to adapt their dimensions to content or screen size? When you resize a window, only the center resizes and the other elements (toolbars, menus, ...) remain unchanged. Most popups have fixed size. It is true for local applications and also for HTML pages. HTML is supposed to be flexible and adapt its layout to content, but in real life, it is really difficult to control how HTML behaves. Apart from fixing elements' size, the result is unpredictable.

Fortunately today we have XAML, and the numerous Panels. Panels are in my opinion the most important contribution to complex application screens. But not every panel is equally useful. Forget about Canvas, which is the old fashioned way of placing element giving coordinates. It is all but flexible. Even the Grid panel that represents a table of cells is not as flexible as my favorite: the DockPanel. It fills up the window space starting from borders, and leaving the center for the main content. Be sure to fully understand how each kind of panel behaves, to be able to choose the correct one. Other useful panels are StackPanel, WrapPanel, ...

Panels come with another important notion: min/max width and height. Instead of fixing a column width, set its MinWidth value. It ensures that it will not render too thin if empty. Avoid at all cost fixing Width or Height, as you never know on what screen your application will be displayed. Test your interface with few or plenty of data, on tiny or huge screens. It should look great in every situation. Panels make it possible.

WCF on Vista raises an AddressAccessDeniedException

2008-04-17T16:55:00.004+02:00

I was trying the example from the excellent book by Michele Leroux Bustamante about WCF, and cound not start them getting the exception AddressAccessDeniedException on ServiceHost.Open().
The solution is to start a console as an administrator (right click on the cmd.exe icon and select "Run as administrator") and execute:
netsh http add urlacl url=http://+:8080/ user=username

The + is a wildcard for any domain

8080 is the port I used for my WCF services, use your own

username is the user you logged in with, and can be preceded by DOMAIN\username

The problem happens only on Vista (and probably on Windows Server 2008) and not on former systems.

WPF is the future of HTML

2008-04-02T16:14:00.008+02:00

I think that all the demos that can be found about WPF and Silverlight are wrong. They are showing how you can make funky animations, include videos and gradient colors everywhere.
But we are professionals and what our clients need is a powerful and robust client, so let's make classical layouts with normal checkboxes and tabbed screens. Nobody needs 3D interfaces where you have to scratch your head to guess how to use it.

Former HTML interfaces were poor and fragile, mixing many languages and standards. How to validate an e-mail input control? Add a server-side validation after postback or use Ajax? Or write a custom JavaScript? Do it on control blur or on keypress? Depending on the context, one of these solutions may do the job so you end up mixing all of them.

With WPF and XBAP, everything is clear. Keep all the client logic on the client, and in the same language as the rest of your code: C#. If you need some info from your database, call a remote procedure using a Web Service. Designing a perfect interface has never been easier: use panels wisely and drop your controls. Bind the numerous events to your actions and the result is there.

I intentionally did not talk about Adobe Air, which is having a similar approach to the light client problem. It is clearly promising and the example you can find on the Internet are much better and mature than those of WPF. However, even if Flash will keep its advance compared to Silverlight, the fact that Adobe Air uses JavaScript and the efforts Microsoft put into WPF makes me think that it is the right choice to make for most client developments.

COMException when opening WebApplication project

2008-03-21T17:11:00.008+01:00

I recently go the following error while opening a Visual Studio solution: "System.Runtime.InteropServices.COMException". Not very explicit, is it?

I found a page in VisualStudio feedback explaining that this is a bug in Visual Studio 2008, that should be corrected "in the next release"...

The explanation is that VS is trying to locate your Web Application in IIS. Look into your project file *.csproj in the <WebProjectProperties> section, the searched URL is indicated in the <IISUrl> tag.

The solution is simple: in the <UseIIS> tag change "True" to "False" and your project will open like a charm.

Form'n'Field jQuery plug-in published

2007-07-04T07:55:00.000+02:00

After long nights of fine tuning and restructuring, the first public version of the Form'n'Field plug-in for jQuery is available.

It helps JavaScript developers to handle client-side forms by giving access to field values in real types and not only strings as returned by DHTML. Why should the value of a checkbox be a string? Isn't it more natural that it is a boolean?

The same applies to listboxes. I often generate listboxes when item names are labels and item values are IDs from by database. Why would I have to convert those IDs from and to strings? I want them to be integers, and that's what the Form'n'Field plug-in does.
But what is the most advanced feature about this plug-in is how extensible it is. You can add your own input type (like a date input with pop-up calendar) easily. Or your complex data type (a JavaScript structure) can be associated with any existing input and handle type conversion and validation.

This plug-in is currently in production in my organization, and I hope that people will understand its value and constructively participate in its development.

Structuring JavaScript libraries: modularity

2007-06-27T15:34:00.000+02:00

JavaScript pop up calendar is a common need, so why does none of the libraries I found match my needs. With Ajax are we often adding an "auto suggest" feature, so why isn't there a library that works in all the situations like auto complete, JavaScript dropdown lists and on-the-fly search boxes?

The answer is simple, all those libraries try to conceal the apparently contradictory needs that are generalization and customization.

We need to generalize to have calendar functions that can be used in all the situations without any modification. To achieve that we strip from the library all the features that are specific to a given case. We end up having a library that does almost nothing, like simply returning days of a month organized in a 7 days × 6 weeks grid.

We need to customize to have calendars displaying week numbers, allowing date range selection or time picking. To achieve that we add the features, and for each of them a flag that we can activate or not, allowing us to enable the feature only when needed. We end up having a library continuously growing, with numerous parameters and difficult to maintain.

The JavaScript language allows easy integration of multiple libraries with the notions of callbacks and object oriented programming.

The idea is simple: define core features and write separate libraries for each of them. Define the data structure that will allow communication between them. Define simple default behaviors for features that can be overridden with additional plug-ins.

If you use only the core library, you have a simple set of features easy to understand and with few parameters. You can plug more features if you need them. You can rewrite your own plug-in - and only this one - if it does not exactly meet your needs.

For a calendar, the code feature is to display a date grid. The data structure is a date value, with flags indicating if a date range is selected. The additional plug-ins could be week number information, enabling selection of a month or a year, adding a second calendar for range selection, allowing time picking.

Each of these plug-ins is obviously small, easy to maintain and debug. You reduce the amount of code to download to the client if you don't use all the features.

A common mistake is mixing HTML rendering with internal logic. Avoid that at all cost, and eventually make the render engine a plug-in.

Creating modular libraries may seem more complicated at first look, but forcing you to think of the structure before you start will make your ideas clearer and you will actually reach your goal faster.

Structuring JavaScript libraries: documentation

2007-06-22T20:59:00.000+02:00

Very few developer like to write documentation. The library they write is clear to them and when the hard work of programming is finished, it is difficult to decide to write the documentation. Unfortunately, without a documentation, your library is completely unusable.

The aim is not to write a long documentation, so the first step is to find what kind of documentation is the most efficient. That means: what is the shortest documentation that will be clear and precise enough.

The easiest one is to write examples. Find a set of symptomatic and concrete usages of you library. This will help users to start using it.
Later when they will need advanced features, another kind of documentation - the technical reference - is a better choice. The reference shortly describes each function, its parameters and call conditions.
Finally I suggest that you write a global description of the library, its philosophy, and general rules that have to be respected. And put it at the beginning.

All together, you have a complete documentation that is easy to write.

The best place for the technical reference is within the source code. Each time you add a new function, write a short description. Each time you modify the function, you won't forget to update the documentation.

Some would say that in JavaScript, the size of the library is critical for download time and interpretation time. Therefore they don't write comments, write compact code stripping spaces and newlines. The code becomes unreadable and difficult to maintain.
This is true but there is an easy solution. Use the JavaScript compactor and provide two versions of your library: the full documented code useful for learning and debugging, and the compacted file for production use.

You don't have any excuse not to write a good documentation. It is not that difficult and you will be the first to benefit from it when you will later reuse the library.

Structuring JavaScript libraries: namespaces

2007-06-20T17:36:00.000+02:00

When you write a JavaScript library, it is important to respect some rules if you want that the library is widely adopted.

The first rule is to avoid conflicts with other JavaScript. This is called leaving the smallest footprint. That means that global variables and functions should be avoided, because another library could accidentally use the same name. The best way is to define a single variable which contains all your code like this:

var MyNamespace = {
    myGlobalVariable:23,
    myFunction:function(x){
        return x * x + this.myGlobalVariable;
    }
};

You should only choose a unique "MyNamespace" that nobody else will happen to use. And if a conflict happens, you only have to change a single name on one place to resolve it.
Then you call your function like this:

var y = MyNamespace.myFunction(4);

There is even a way to leave no footprint at all by hiding your code into an anonymous function:

(function() {
    var tDays=['Monday','Tuesday','Wednesday'];
    for (var i=0; i<tDays.length; i++)
        alert(tDays[i]);
})();

The drawback is that you can not reference that code from outside.

The second important rule is to write a documentation, and I will detail it in another post.

Typed variables in JavaScript

2007-06-14T12:49:00.000+02:00

JavaScript is a rather permissive language, and it lets you write code without annoying you with variable declaration or typing. It is good for simple functions like this:

function selectOptionByValue(oSelect, value){
    oSelect.selectedIndex = -1;
    for (i = 0; i < oSelect.options.length; i++){
       if (oSelect.options[i].value == value){
          oSelect.selectedIndex = i;
          break;
       }
    }
}

with the following HTML:

<select id="qualitySelect">
    <option value="0">Bad</option>
    <option value="1">Average</option>
    <option value="2">Good</option>
</select>

if you call:

selectOptionByValue(document.getElementById('qualitySelect'), 2);

the "Good" option is selected.

But what really happened? The function compared the value "2" associated with "Good" with the integer 2.
This is convenient as you don't have to think of it, it works.

But in more complex projects, this permissiveness can make debugging extremely difficult. If you assigned a variable that you were considering as an integer with a string value, all your next processing will fail, but JavaScript will not complain. So a bug that could be detected early arises much later, in a completely different place.

There is not a single solution for this, as JavaScript is not a compiled language where the compiler could signal incorrect type assignments.
The first thing is to declare all variables with "var".
If you want to compare two values in a typed way, use === instead of == and !== instead of !=. '2' == 2 is true where '2' === 2 is false.

A good starting point is to use a tool like the free JSLint that warns you about all the risky code that could hide potential bugs.
This will not eliminate all the bugs from your code, but help you concentrate on the logic instead of the syntax.

JavaScript Closures and memory leaks

2007-06-05T13:45:00.000+02:00

You sometimes use techniques unconsciously, and you discover it later when trying to locate a bug. Closures in JavaScript is one of those. If you create functions dynamically, you often create a closure:

function formatMoney(sFormat){
    return function(iAmount){
        return sFormat.replace('[amount]',iAmount);
    }
}
var formatEuro=formatMoney('[amount] €');
var formatDollar=formatMoney('$[amount]');
alert(formatEuro(12)+' - 'formatDollar(23));

displays "12 € - $23".

You can notice that the sFormat variable, declared outside the function definition is still present when the function formatEuro is actually called. This is possible because JavaScript creates an object with the dynamically created function and its context with the local variables.

Why does this provoke memory leaks? Well, it shouldn't, as JavaScript has a garbage collector, and the objects created on the fly are freed when needed. But some browsers (IE?) are worse than others on that aspect, and circular references, particularly between JavaScript and DOM objects remain locked.

Taking care of memory leaks becomes more important as we create Ajax applications that do not jump from page to page, and do not give an occasion to the browser to completely flush its working memory. Badly designed Ajax applications can increase the memory used by your browser to a point that locks your computer completely.

A good article at ibm.com explains what are the common patterns leading to memory leaks, and a few solutions to avoid them.

Handling forms in the browser

2007-05-31T08:54:00.000+02:00

With the increased use of Ajax, form handling has evolved. Even if user needs are the same, the developer has new constraints faced repeatedly. There is obviously a need for a JavaScript library solving the following points:

filling a form with data. Now that data is dynamically loaded with Ajax, the HTML form is empty and data, often provided as a complex object, has to be transferred, types converted, etc.
field validation is not a new problem, but calling a server-side validation function on each user action is not a fast enough solution. Calling it when the field loses focus is too late as it forces the user to get back.
extracting data on user submit, converting them again to a complex object to be sent by Ajax.

Doing these steps for each form increases the code size and the potential bugs, and quickly becomes boring...

As I am working with jQuery, I started looking at existing libraries, and some of them actually solve some of these points, but partially.
The first library to look at is the "official" Form plugin. Unfortunately the main aim of that library is only to submit forms with Ajax instead of a normal POST request. Sending data with Ajax is for me a separated task, as all forms are not necessary sent to the server.
Other libraries offer form validation, like the recent ValidationAide, but are either poorly isolated from other functionalities or reduced to a set of regular expressions.

As often when a need is not satisfied, I decided to build my own library with the following features:

handling of form content filling and reading
field validation
separation between form and field functions
no functions for submission (rather using jQuery+JSON functions or AjaxPro)
no superfluous features
full customization available, with lot of default behaviors

and naturally the library will be offered to the community.

A bridge between JavaScript and C#: AjaxPro

2007-05-29T15:53:00.000+02:00

It is now very common to JavaScript programmers to call remote procedures on the server, either directly using the XMLHttpRequest object or a framework ensuring cross-browser compatibility.
What is then missing is the server-side machinery able to answer the request. You have to parse the request parameters, process data and build a return value as a string or an XML document. It is relatively simple as long as you are using basic types, but gets complicated if you want to pass a custom object or a DataGrid.
If you are lucky enough to be using .NET, here comes AjaxPro. You create an .aspx page with a public class MyClass. Add a public method MyMethod with the attribute [AjaxPro.AjaxMethod] and that's all. You are now able to call your remote method from JavaScript MyClass.MyMethod(...) just like if it was locally on client-side.

The best part for me is the following: the AjaxPro project manager is planning to make it compatible with jQuery, i.e. make AjaxPro generate JavaScript proxies with the jQuery framework. This will lead the ease of programming and abstraction level one step further.

Discovering jQuery

2007-05-26T14:49:00.000+02:00

To ensure cross-browser compatibility in my web sites, I used to use the library from cross-browser.com.
It has interesting features, like providing a "compiler" that extracts only the functions your page actually uses from the library and builds a customized compressed JavaScript file. The form of this library is rather classical, you have a set of functions that you call when needed, no classes or object oriented programming.

I recently discovered jQuery, a JavaScript framework that is a bit more complicated to use, but that allows you much shorter and often quicker code. I recommend it for larger projects. The philosophy is rather different, and explanations would be too long here.

It also has a standardized way of adding libraries, which resulted in a long list of features developed by the community. One of them is Interface allowing animation, drag&drop and many other things with incredible ease.

As I continue using jQuery will I post remarks and tips here.