Have you also had some mysterious AJAX error/bugs/strange behavior? If does, this following link maybe will be helpfull for you... Dave Ward speards 2 common mistakes about it here.

BTW, Found it through ScottGu's blog.

Enjoy

After a year and a half of posting (most of the time) not included weak periods of time, Google ranked me as 4 in their PageRank.

I just want to mention it, KUDOS

I had a little debate (friendly one of course) with one of my work colleagues, caller Lior Alon about the usage and the necesasry of this technique. At the start of our conversation we disagreed on several things like: "It must stay for the good work flow", "This is by Microsoft design - do not touch" and more and more...
But at least we agredd that in some cases this ViewState is unnecessary and it has some disadvengtages that come over the adventages in some cases.

From the initial point of view, I would change the ViewState behavior. By defaut the ViewState of each ASP.NET web page is always on, so when you develop a new page you need to consider that the ViewState is on - so expect to amount of encrypted lltterals on the top of your page (according  the web server controls that you rendered on your page).

This issue has some disadvanteges as I said earlier:

1. Big size of data that comes from the sevrer to the client (response time concerns).
2. SEO (Search Engines Optimization) - Most of the seerch engines doesn't indexes the whole page (and I think non of then but I am not sure of it). The exsitance of the ViewState in the top of the prevent these search engines from index the relevant data from the specific page and here the ViewState takes its place. Here comes the question why the ViewState must be on the top of the page instread of its bottom?
3. By default the ViewState in on; In some cases, static pages contains web server controls that doesn't need to be updated from the server by the user demand. In this case each control has its own ViewState and it being populated to the bunch of the ViewState's encrypted data. (In that case you can develop this page using HTML controls that doesn't drag to the page 'added value'...

So, to the conclution...

ViewState is not bad thing, but like everything in life has some good and bad 'habbits'. After time of thinking, I think that the default behavoir of the ViewState should be off and the developer that creates her ASP.NET web page should be smart enough to use it wisely.

What do you think?

As you know (if you're checking up this blog once on a while) or now, I am leading the technologic part of an application that we're working on the last 6 months, and this application (web) is multi-lingual.

The case: In order to read properly some configuration to the application, we are using an XML that represents some flow steps, for example:

<activePages>
   <page url="<some url>" ordinal="1" isInitial="true" />
   <page url="<some url>" ordinal="2" />
   <page url="<some url>" ordinal="2.1" type="US" />
   <page url="<some url>" ordinal="2.2" />
</activePages>

This XML structure is being read into an object that need to be saved in the application output cache for further usage. As you can see, the 'ordinal' field need to be converted into a double (or float) member in the cache's memory object.

While doing some Unit Testing on the application and changing the culture on runtime into French (or other European Language), the XML read action was failed and threw an exception.

Is'nt it Strange? In fact no!
After some googling I found that the European cultures/ languages numeration syntax is different than the US of the Hebrew, for example 1.1 will be written as 1,1 using the European language.

At least (as an addition to the bug resolution) I learned something new regarding enumeration... ;)

Lately I am focusing more and more on the Ajax.Net extenstions and framework in order to assimilate it wisely in my woring on web application. In general the .NET guys did here great job, created here realy a whole framework that includes new controls, namespaces etc... The outcome of it is good, it supplies us what we want doing it in quite easy way, there are nice webcasts, tutorials and lots of documentation that explains how to use it, but it's has also a (little?) disadventage - the actions' performance are quite bad in comparison to other open source tools, like Anthem.Net and more, you can impress of it here.

Until here is the post's intro... ;)

I investigated some the UpdateProgress control, it is nice one and supplies great usage and can gives us great UI results in a few minutes of simple actions. By investigating the source code of a web page that uses this control, I resolves this related code:

<script type="text/javascript">
<!--
Sys.Application.initialize();
Sys.Application.add_init(function() {
$create(Sys.UI._UpdateProgress, {"associatedUpdatePanelId":null,"displayAfter":500,"dynamicLayout":true}, null, null, $get<Update_Progress_Control_Client_ID>));
});
// -->
</script>

It's nice and being generated automatically of course, but what if you need to do some more actions while the callback action is under progress (you can think of tons client side actions, right?).

In this case I would suggest to abandon the UPdateProgress (great!) control and to implement this action by yourself in javascript using the Ajax client-side API, take a look of this one:

<script type="text/javascript">
    Sys.WebForms.PageRequestManager.getInstance().add_beginRequest(
        function ()
        {
            // Do your actions...        
        }
    );
    
    Sys.WebForms.PageRequestManager.getInstance().add_endRequest(
        function ()
        {
            // Do your actions...
        }
    );
</script>

Using the Sys.WebForms.PageRequestManager object, you can add/remove handlers to the Ajax client-side Life-Cycle events and do your stuff in a focused and single place -> much more easier to handle and to maintain.

I decided to publish some more nice pics of my son Ori (I thinking about registering him a domain - myabe I'll start blogging sometime... ;). I can't belive that he's almost 3 month old may have many happy returns...

Ori with Tzippi...

Ori is focusing...

Ori is playing his 'University'...

I wouldn't call it a problem/error/bug/you can call it how you want, I'll call it a moment of idiotic lack of attention?

I struggled with a very common problem (it seems to be a common after some googling): "My Global.asax events are not being constructed/called - what should I do?"; this one was so familiar and I was sure that I've done everything like it has to be, so again what was it?

Finally I figured out my problem myself and was supprised of it (I'm seriously not jocking), the Global.asax file was not placed under the root folder of my web application (my web aplication structure is quite 'complex' because it suppose to serve many web sites that sits also in the same solution). I replaced it in the right folder (the one that the IIS is pointed to) and that's it.

I think that post can solve to (starter?) web developers this (common?) problem while it occurs, because google's results didn't supply very good solutions for this one.

What aobut me? Even after developing and designing many web applications, things like that could happen to anyone

Firstable, before I am going to write the following words, I want to mention and admit that I am realy a big fan of Microsoft technologies, its innovetions and its line of philosophy; Most of the time they are doing good job (in some cases I would implement some things in other way, but this issue if for other post...).

What I want to talk about in this post is the C# language's development from the first version of .NET until the further to come which is .NET 3.5 in Visual Studio 2008.
In the beginning of .NET 2.0 there were great and major language improvement, like generics, anonymous methods/delegates and more nice things (that indeed, helps us to write more nice, agile and elegant code). BUT major things often require new keywords to support the 'enhanced' language, for an example: the <TEntity> syntax in order to use and implement generics.

In the generics case, this syntax is required in order to make a usage with this great feature, but in most cases new keywords are BAD, just bad because developers have the annoying habit of using non-keywords as identifiers. An example for new keyword is the pair: return yield. In the first version of iterators, you had to use yield when you wanted to "return" an iterator value back, and as we know everything worked just fine, so why should they need to add the return keyword in order to return the iterator's value? (I'll be glad to get the answer if you got it...)

I tried to figure out and see what Microsoft tried to do regarding this issue and found that they ment to provide a utility that you could run over your source code, and it would replace any identifier that had become a keyword with the escaped version. It should do this by putting an "@" sign in front of it. I don't think that tool at least was published...

Today, just before .NET 3.5 is releases out (not in beta of course), we can see on beta versions and examples the new keywords and innovations that had been added to the language which demands from us to adjust ourselves to the new syntax.

At the bottom line, it makes us a little bit of hard time at the begining, but it enhances our language and gives us a learning challenge and the ability of upgrading our code (maybe not easy to read on the first time but easy to implement and to make it more agile and generic). 

I encourages these changes, but don't forget - everything could work just fine without these new stuff.