Tales from the Evil Empire

Bertrand Le Roy's blog

News

Ads Via DevMavens

ASP.NET AJAX UpdatePanel Control: Add Ajax interactivity to your ASP.NET 2.0 web pages


follow bleroy at http://twitter.com


Add to Technorati Favorites

Blogs I read

My other stuff

Posted: by

Comments

Tom said:

Thanks Alister and Betrand for this nice thread :).

Well lets me give you my point on this.

I think that most of the arguments presented here are a bit "off road", if I take the SQLDatasource comment, yes its bad to use sql statements inside a page but how many ASP.NET 1.0 books today are already presenting their samples with this bad technic ? ... Let's face the truth ... How many hobbysts or even developpers know or care about ntier, MVC etc ... architectures anyway ...

The real problem does not lies in the tools but how people use them ... I agree .... There is a lot new stuff in Whidbey some on which I am also very sceptical about like the code beside model for example or mixing again code & design on the same page even if its hidden by the IDE ... But still these are just new tools to add to your bag during your development road and you must only choose the right one at the right time.

One of the hardest part now is the richness of the framework which is getting so big that its becoming diffcult to have a big picture or to choose the right tools at the right time until you've gone through almost everything, which (can) takes some (lot) time. But I doubt that it was an easy path when you learned ASP.NET 1.0 for the first time also. New features / products take always some time to get through before you see and get all the benefits, but it seems to take more and more time for each release.

People, in particulary hobbyst, have a strange image of computing. The image of being an easy path that do not require any effort to do something and that everything will come together like magic. It's not and very far from being the case. Do I sit down in a car and drive down the highway without having my driving licence first ? Not until we invented a fully automated car that drive me where I want to go ... Everything needs time to learn ... Yes some things can be easier to learn than others but cluttering down features wont help, lets take a simple example there are tons of vb programmers who struggle learning the object model of .net. Should we go back to quick & dirty model of vb instead ? I don't think so ... So what's the solution ?

Microsoft is trying to address the needs of two kind of totally different people working on totally different projects with totally different technical backgrounds ... The hobbyst and the enterprise developpers ...

Two kind of people for one framework, that must be a big headache for them ... The only "exit" I see could come from two totally different IDE's. Visual Studio has become a great IDE, but it's just too much and too expensive for any hobbyst who wants to use it. So the weak point here is clearly webmatrix, don't get me wrong ... Its nice, its free but I believe it's not matching what hobbyst are waiting for, an easy , cheap and very visual tool with a low learning curve, with many default and easy to modify templates / tools and no code at all. Whidbey has all the inner working to do such a tool .. So where is it ?

Communication is also a huge problem, there are so many different features in products today targeting so many different people that it's almost impossible to communicate correctly. For whidbey in a sense there is too much communication about a product that won't ship till next year. For people who are interested like me in what's comming next its great to see where it goes but that might too much for others ... As a developper I percieve the whidey communication as if MS is already, in a way, cluttering down .net to attract hobbyst and promotes bad design which is exactly the opposite feeling of Alister's one ... Its not my opinion but its just how I perceive the MS communcation at first without hands on the product ...

About PHP ... Is it really because it's so easy to use and to understand that most people use it ? Probably there is some "marketing" truth about this statement but let's look closer, Apache has almost 70% of the hosting market ... That might be another good reason why it's so "popular" ... MS needs to work on an "hobbyst" targeted IDE but if they really want to hit their hobbyst target they will need to increase their web market shares among hosters ... If IIS had 70% of the market share I am quite sure that this, great btw, thread would never have existed.

Anyway many thanks to Alister for startic this interesting topic ...
# June 16, 2004 7:13 PM

Bertrand Le Roy said:

Thanks for the comments, Tom. Right to the point, as always.
Your points on a hobbyist IDE are well taken... You're absolutely right. WebMatrix was a good start, and we must not stop there. Especially with Eclipse on the "other side".
About PHP, you're absolutely right too, and to make ASP.NET as popular in the hobbyist market, we have to increase the number of cheap to free hosters. We also have to make it easy to host from home. We're working on that too.
# June 16, 2004 7:13 PM

Jeff said:

So where is it?
# June 17, 2004 12:21 AM

Bertrand Le Roy said:

Click on the title...
# June 17, 2004 1:10 PM

SomeNewKid said:

This thread has been reproduced in its entirety on Paschal's weblog:
http://weblogs.asp.net/pleloup/articles/155954.aspx

I wasn't too keen on the word "debate" but, other than that, the reproduction was introduced with a complimentary preface.

Thanks again, Bertrand, for the time you invested in answering the concerns I raised.
# June 18, 2004 12:13 AM

TrackBack said:

TheServerSide.NET
# June 18, 2004 7:33 PM

TrackBack said:

# June 23, 2004 3:56 AM

Erebuss said:

C'est pas drole si les VBistes ont notre using maintenant aussi ;)
Bon, bonne nouvelle, je connais un nouveau mot clé de Vb.net 2005 alors :D

/GP
# July 6, 2004 2:23 PM

Jerry Pisk said:

No it doesn't. The rule is "no business logic belongs to the view (an ASPX page in ASP.NET)", not "no code belongs to the view". There can be code in the view, but not business logic code (or anything else business logic). Database connections are business logic, not views, and as such they do not belong to the view, even if you wrap them so you don't actually have to put any code there.

But you're right in one point - ASP.NET is not layered. An ASPX page is all three layers in one, it's the controller, the business logic and the view. No separation there at all, no matter how much you and Microsoft keep repeating that there is.
# July 12, 2004 4:23 PM

masqued vengor said:

Hey Bertrand, move on blogs.dng ;-)
# July 12, 2004 5:40 PM

Bertrand Le Roy said:

Jerry, you just don't get it.
Data sources are NOT business logic.
No matter how you write your applications, your presentation layer will always have to communicate with the other layers. Data sources are just a declarative way of communicating with other layers.
Yes, there can be code in the view, but there should not be code in a declarative surface such as the CodeFront. But you're right in pointing out that it's not a matter of code or no code.
Data sources are NOT database connections, they are a way for the presentation layer to communicate with other layers.
The Page Controller is not business logic either. The only code you should have in there is the code that orchestrates the UI elements and the code that establishes the communication with the other layers.
My whole point is the the communication code has always been in the page (it has to be, there has to be a way for the data to get into the Template View), it just moved from procedural to declarative.

ASP.NET does NOT contain the business layer unless you want it to be there, and we all know this is not good architecture.
But many many people are doing multilayered architecture with ASP.NET and your statement is just a troll.
As many people, you're thinking in J2EE terms. It is not because ASP.NET adopts a different angle that it's wrong. And surprise, JSF adopts almost the same architecture. Why would that be??
# July 12, 2004 5:55 PM

TrackBack said:

# July 12, 2004 6:01 PM

SomeNewKid said:

From my extended mail conversation with you, Bertrand, I took away two concepts that I feel underscore ASP.NET's strength and beauty.

The first is the concept of the Page as an application surface, not a UI surface. It is a powerful concept, and I had already added it as an epilogue to Paschal's archive of our conversation:
http://weblogs.asp.net/pleloup/archive/2004/06/18/159085.aspx

The second is the concept of CodeFront and CodeBehind representing two sides of the same coin ... declarative and procedural programming respectively. The more logic we can represent declaratively, the more powerful and graceful ASP.NET becomes.

Now to see the Page as an application surface, one that does not invalidate n-tier development, requires that developers view their app from a different perspective.

Current literature always shows an application from a "side on" view. Here, we see a data store at the bottom, above that a data layer, above that a business layer, and above that the UI layer. Business and UI processes may represent additional layers.

To best understand the ASP.NET Page, we must swing our view from "side on" to "above". Having done so, we can understand the Page as a topographic map of the entire application. That "pool" of data on our map may be a shallow pool (perhaps drawing directly from an XML file), or it may be a deep pool (with data having risen from a different physical tier, through a data layer and business layer). This analogy illustrates the power of the SqlDataSource and ObjectDataSource respectively. Looking from "above" the application, they may look similar, but their depth is completely different.

Before I took this new "from above" perspective, I found Whidbey troubling. Now, having taken this new perspective, I find Whidbey beautiful. It may be a strange superlative to apply to a development environment, but I truly find ASP.NET's declarative model to be a thing of beauty. Powerful, graceful, beautiful.
# July 12, 2004 6:46 PM

Bertrand Le Roy said:

Thank you so much for this comment, Alister, I really appreciate. So, when are you getting a blog?
# July 12, 2004 6:50 PM

Kevin Dente said:

The data source stuff is very cool, and I'm looking forward to being able to take advantage of it. But why do data source controls appear on the visual portion of the page when they don't generate any visual representation? It sems like the component tray was originally intended to hold non-visual design elements, but ASP.NET never really took advantage of it the way WinForms did.
# July 12, 2004 11:30 PM

Bertrand Le Roy said:

Kevin: I personally am uneasy with the way non-visual elements like DataAdapters used to appear in this component tray whereas it's not part of the markup (ie, the declarative part of the page). Why DataAdapters and not any public property of the page, then? Of course, the answer is that only Components appear there, but for most users, it is not clear what a Component is, so it seems quite arbitrary.
Now, data source controls are part of the markup, so they appear on the design surface like any other control. If you see the design surface as the visual representation of the markup, there is no reason why it should behave any differently than other controls.
Another reason is that it is perfectly possible for example to put a data source control in a DataList template to do hierarchical binding. Of course, doing that with a SqlDataSource would most of the time give catastrophic performance, but doing it with an object data source could make perfect sense. Don't get me wrong, there are better ways to do that, but it is still a reasonable scenario and one that we're allowing. Well, in this case, the data source couldn't be in the component tray because its data container is important in this context, it's not directly under Page, and it is repeated.
ASP.NET is closer in its spirit to Avalon than to Windows Forms anyway (which is not a surprise when you know the people behind Avalon...)
# July 13, 2004 2:45 AM

TrackBack said:

See also http://techno-weenie.net/blog/code/95/net-20-datasource-controls
# July 13, 2004 1:53 PM

Kevin Dente said:

Bertrand: The way I see it, there's actually two separate issues here: 1) does the control persist as markup on the page, and 2) is the control displayed on the visual design surface, along with "visual" controls.

Personally, I think that the notion of a separate area where non-visual elements are displayed (even if they actually "live" as markup on the page) is a useful one. Putting them on the visual design surface strikes me as potentially confusing. Where should they go? Does it matter where they live on a page? Where do you shove them so they don't interfere with your visual layout (especially in a flow layout, where they occupy space in the flow and change the layout of the page)? Fortunately, I see that Whidbey has an option to hide non-Visual controls - but of course then it's not obvious that they exist at all, and if you unhide them, it reflows your page.

I do see your point about the data-source-in-a-template case, although it seems like there could be another solution. I'll have to think about that one... ;)

Side question - how does one flag a control as non-visual in Whidbey?

# July 13, 2004 4:27 PM

Bertrand Le Roy said:

Kevin: It doesn't matter where you put a data source on a page as long as you don't need it inside some container, so I'd put them at the end of the page so that they don't disturb the rest of the visual layout.
To make a control non-visual, just mark it with the [NonVisualControl] attribute...
# July 13, 2004 5:55 PM

Kevin Dente said:

Bertrand: Yes, I realize that. My point was that rendering the non-visual controls inline in the page forces the page designer to be aware of and accomodate those issues. Personally, I would rather just see the non-visual controls down in the tray. But that's just my opinion.

Thanks for the NonVisualControl pointer.
# July 13, 2004 6:30 PM

Laurent Kempé said:

I have to say that I second Kevin. Having the non visual controls in the flow is really annoying.
# July 22, 2004 6:40 PM

Bertrand Le Roy said:

This kind of choice is not made whimsically. It relies on usability studies, which means that while some may find it annoying, most people like it better this way.
As you have an easily discoverable designer option to make non-visual controls appear and disappear at will, I don't think there's much more we can do...
# July 22, 2004 6:44 PM

TrackBack said:

Sami Jaber's contribution to the dabate (french)
# July 23, 2004 9:34 PM

Mike Kozlowski said:

That Oracle article was one of the lamest, most preposterous pieces of cheerleading I've seen since Dave Massy said that he was afraid to use non-IE browsers for security reasons.

I mean, c'mon, PHP? Back in 1996, when I was writing CGI apps in Perl, I would've turned up my nose at PHP. It's a horrid little hack of a platform that nobody in their right mind would ever want to use -- it's as if somebody saw ASP (a horrid little hack in its own right) and made a cheap rip-off without even bothering to develop a proper language in which to embed their page-template stuff. At least when Sun ripped off ASP with the original JSP spec, they had the decency to graft it on top of fundamentally sound technologies.

But not only is PHP bad in comparison to other antiquated techniques, it doesn't even bear comparison with modern development methods. JSP 2.0 with JSTL (and possibly JSF, which I haven't had a chance to really try) is amazingly better than old, hackish JSP. ASP.NET is incredibly advanced over old, hackish ASP. PHP 5 is... a slightly better lousy hack than it used to be. Um, yay.

# July 23, 2004 9:42 PM

Andrew Storrs said:

I know many former PHP programmers (myself included)...

"former"... Nuff said. :)
# July 24, 2004 2:27 AM

Muntedhar "Pzycoman" Alhakim said:

That article is just plain silly.

It lists ASP.NET as Slow, as opposed to PHP which is fast.

I did this tests a long time ago (about a year, maybe more) - http://www.pzycoman.myby.co.uk/lspeed.html

Even with a precompiling doohicky (Zend Accelerator) (Which kind of makes the tests unfair, as there arnt many ASP.NET accelerators), its still as slow as a 3 legged rocking horse.

In the same time (roughly) it took PHP to do 8 million calculations, ASP.NET did 1.6 Billion.

Enough said :)
# July 24, 2004 2:47 AM

Matt said:

That's a very basic test, and I hope the results aren't due to compiler optimisations. The compiler should be able to get rid of the comparison entirely!
I prefer ASP.NET myself, but that test is as bad as Oracle's info.
# July 24, 2004 3:39 AM

Jouni Heikniemi said:

Bleroy: Many good comments, too bad some of them got a bit too biased and personal - they're just eating the credibility of your writings.

There's one point I'd like to comment on: "Open-source opportunity. Sure, if that's important to you. If accountability is more important, then I guess that's a different story." I don't think there's much Microsoft can defend itself with against that claim. For most products, I can't really say MS has been very responsible and accountable. The lack on open information flow and the relatively slow speed of fixing bugs and providing patches is certainly a factor when considering whose products to deploy.

Many open source groups manage to provide much more reliable and useful customer support than Microsoft has traditionally been able to offer. This especially has been true for many of the Internet applications. Add in the possibility to do (no matter how unsupported) custom hacks, and there certainly has been an air of flexibility around LAMP platforms when compared to the stagnation of ASP.

That said, Microsoft has taken significant leaps with ASP.NET, the new developer community (not to ignore this blogging business) and now with Whidbey's relatively open bug tracking. Even though the direction is right, you'll need years more to convince people to trust on Microsoft's accountability. One of the greater things working for you is the developer community that now has sufficient role and publicity to actually make things work. Some people will be very dubious, but time is a good healer.
# July 24, 2004 4:19 AM

TrackBack said:

# July 24, 2004 4:28 AM

Bysza said:

Oracle article sucks...

Since I can't say more than all my predecessors already said, I may pinpoint this: section "Database Coding Examples", "ASP.NET Connecting to Oracle" is... wrong.
It's not ASP.NET connecting to Oracle, but a *console application* connecting to oracle and printing two column contents to the console... :D
# July 24, 2004 8:55 AM

TrackBack said:

ASP.NET vs PHP - Counterclaim to Oracle's FUD
# July 24, 2004 8:58 AM

Bertrand Le Roy said:

Jouni: I won't pretend I'm not biased. I work for Microsoft. I just hope that I'm less biased than the Oracle article author.
But what I mean by accountability (at least for ASP.NET as that's my team) is that if you have any trouble with our software, you know exactly who to turn to, and you can be sure that support or direct contact with one of us through mail, newsgroups or the ASP.NET forums will very quickly find a solution.
I know that when I was a Microsoft customer, every time I had to use the support, I got commitment and I got a solution.
I also know that the last time there was a widespread virus/worm for Windows, there was a company-wide effort from many non-support employees to provide free support to the general public to help get rid of the vermin.
We still have some progress to make, in particular for community support, but I think we're getting there fast, as you seem to have noticed.
# July 24, 2004 10:04 AM

Larry Osterman said:

It's off topic, but, I've got to ask: Bertrand, how did you get real links to show up in your comments section? Every time I've tried to do that, the HTML gets quoted...
# July 24, 2004 12:18 PM

TrackBack said:

Well, I don't agree that PHP is any simpler for beginners, especially with Whidbey. Our usability studies show quite a different situation. It certainly looks more familiar to people who have done some classic ASP or JSP development, but a complete beginner will start faster with VS.NET + ASP.NET than with PHP...
# July 24, 2004 2:36 PM

Jouni Heikniemi said:

All right Bertrand,

Since you almost asked for it ;-), I'll use this opportunity to ask you for an answer to one of my news group postings quite some time ago. Any chance you could tell me what's going on in the following:

http://groups.google.fi/groups?selm=Xns949197CADD5E4jouninews2heikniemin%40194.100.2.89

Unanswered mysteries are the things that make me yearn for a totally open bug reporting system. Let's see if this one actually becomes a non-mystery :-)
# July 25, 2004 1:11 AM

Bertrand Le Roy said:

Jouni: First check this: http://support.microsoft.com/default.aspx?scid=kb;en-us;833268. I don't think this is your problem, though, but it's worth checking.
Your problem is probably a conflict that happens when you hit the second control. Naming conflicts can appear as all pages and controls are automatically compiled into the same _ASP or ASP namespace. In Whidbey, this problem was solved, but in the meantime, the recommended fix is to specify the ClassName explicitly in the @Control directive so that even though the file name is the same, the controls will have different class names.
# July 25, 2004 3:00 PM

Jouni Heikniemi said:

Yep, that much I figured and we've been using ClassName already. It's a bit problematic at times, but it does fix the immediate problem. Looking forward to Whidbey, then. Thanks for confirming my thoughts on the issue. Another score for Microsoft's developer support - keep it up :-)
# July 25, 2004 3:49 PM

DevNull said:


PHP runs on almost every platform ASP.NET does not.
PHP runs on over 60% of the webserver today ASP.NET does not.
PHP is free/open ASP.NET is maintained by one company.

the above things a for me way more important that if its takes 5 or 7 seconds to get a result. ASP.NET may be faster but i guess its a lot more restrictbie and un-flexiable than PHP.

# July 26, 2004 6:43 AM

Toast said:

Personally, I prefer PHP as I'm not restricted to any platform. I've got Apache, PHP and MySQL running on MS and OSX and Linux and for the hobbyist developers without a corporate budget or enough cash around, going for a LAMP setup is a lot more realistic.

Another thing I like about PHP is the extensions that can be got for it. From different databases to graphical libraries to PDF generation to SWF generation, there's a lot that can be done and even though PHP mightn't be as english-like in its syntax, once it's practised, it's no problem to read and write.

That's my two cents anyway.
# July 26, 2004 7:12 AM

Richard Moore said:

The file open example is still wrong in your corrected version - it ignores the possibility that the file exists but is not readable by the user the script is running as. A better solution would be to try to open the file and either handle the resulting exception or rethrow it.
# July 26, 2004 8:14 AM

TrackBack said:

I read this in the comments to a reply to the PHP vs ASP.NET crap Oracle posted. Mike Kozlowski wrote: That Oracle article was one of the lamest, most preposterous pieces of cheerleading I've seen since Dave Massy said that...
# July 26, 2004 9:04 AM

Caruccio said:

"Memory that's not used is useless."

today, 1GB RAM is not enough for a web server... if all your process become memory-eaters, your server will get down soon... at this point, I think ASP.NET fails (like almost Microsoft solution).
# July 26, 2004 10:25 AM

abc said:

hey,

why all think that ASP.NET runs only on MS Windows?
look at http://www.mono-project.com/about/index.html


some fixes for:
1. PHP runs on almost every platform ASP.NET does not.
2. PHP runs on over 60% of the webserver today ASP.NET does not.
3. PHP is free/open ASP.NET is maintained by one company.

solutions:
1. use mono
2. apache + ASP.NET mono module
3. 1, 2 -> ASP.NET is !!!NOT!!! maintained by one company.

# July 26, 2004 10:32 AM

Shike Maffer said:

abc's comments mirror mine...if multiple OS's is the acid test in the argument, why not consider mono?

There is nothing in PHP that you couldn't do in traditional ASP. With ASP.NET, Microsoft addressed many things and turned it into a real web development architecture. If you don't like it because it's Microsoft, that's fine. But as Bertrand points out in his response, the real agenda here is Oracle. You remember Oracle, the company that is in bed with Java? So why pimp PHP? Simple, because Oracle dependence is OK, Microsoft dependence is not. Dead on Bertrand, dead on. Oracle has been whining about Microsoft's dominance for years...they aren't arguing against market dominance/reliance...they're arguing about it not being to their benefit. Oracle and Sun (to throw them in here too..) have always shown that when they are the vendor that you must rely on, that they are as ruthless, gouging and uncaring as they claim Microsoft is.

And lastly the chart in the article is lame, but I've figured out the scale: $$ is better than $$$, but worse than $. So there you have it.

Shaffer
# July 26, 2004 10:53 AM

dick tang said:

>Then, let's look for vulnerabilities: choose Microsoft / IIS / 6.0. >Results:
>1 (One!) x-site scripting vulnerability in a web administration >tool that's not even installed by default
>And three for ASP.NET

>OK, let's do the same for Apache 2. Results:
>25 (Twenty-five!) vulnerabilities, including DOS and Buffer >Overflows
>Wow, that's a lot! Let's look for PHP 4 now... Results:
>19 (Nineteen!) vulnerabilities, including integer overflows, >arbitrary file disclosures, cross-site scripting, etc.

that's not fair,how long did apache and php releaese?
I agree that IIS 6 is securer than before,but you should not list
ps. 25 vulnerabilities is not usually affect all of the platform
# July 26, 2004 11:01 AM

General Protection Fault said:

For Shike Maffer:
"There is nothing in PHP that you couldn't do in traditional ASP. "

That's B.S. In old-school ASP, to rotate an image, you had to buy a third-party COM library like LEADTools. PHP handles this natively with the image* functions. Likewise, for creating PDFs, PHP has built-in support but ASP does not. Add all those COM libraries on your TCO!
# July 26, 2004 11:06 AM

Oscar Leeper said:

So if following the link off VA Systems owned propaganda mouthpiece Slashdot wasn't enough of a clue, I just watched the page load on the Oracle article:

1)Click on link
2)Oracle banner appears at top of page

And there I sit thinking to myself, "Yup, another piece of Oracle FUD. This should be funny."

Thanks Bertrant, for putting into words what every *level-headed adult* programmer was thinking upon reading the article(or the banner at the top of the article).
# July 26, 2004 11:38 AM

Yeehaw said:

"the author tries to convince us that PHP and ASP.NET fall into the same category of web platforms that '[embed] code into HTML pages with special tags that signal to a preprocessor that they contain code, and that it should do something with it'. This is true of PHP, but not of ASP.NET, where the code can, but should not be in the HTML markup."

Code and HTML should be separated (most of the time) in both languages, and it's just as possible to do this in PHP as in ASP.NET. I stopped reading your rant seriously at this point, because it showed that you are at least as dishonest as the Oracle writer.

I also love how you defend that ASP.NET is tied to IIS by defending the *security* of IIS. That's really rich. I stopped reading altogether at that point. Your are obviously on the far-away planet Microsoft at this point.

A bunch of developers are building large, fast, powerful, scalable programs quickly and maintainably using completely free and open tools. They don't need you, and ASP.NET would have to be *far* superior to warrant marrying your company and shelling out a bunch of cash. But I'm sure you'll find a way to shrug this off and still be 'right'.
# July 26, 2004 11:56 AM

Jason Lotito said:

some fixes for:
1. PHP runs on almost every platform ASP.NET does not.
2. PHP runs on over 60% of the webserver today ASP.NET does not.
3. PHP is free/open ASP.NET is maintained by one company.

solutions:
1. use mono
2. apache + ASP.NET mono module
3. 1, 2 -> ASP.NET is !!!NOT!!! maintained by one company.

Unless I am mistaken, ASP.NET is NOT covered by any open standards, therefore making it's legal standing unsure. Indeed, from the MONO page:

"The controversial elements are the ASP.NET, ADO.NET and Windows.Forms subsets. Those are convenient for people who need full compatibility with the Windows platform, but are not required for the open source Mono platform, nor integration with today's Mono's rich support of Linux.
...
The Mono strategy for dealing with these technologies is as follows: (1) work around the patent by using a different implementation technique that retains the API, but changes the mechanism; if that is not possible, we would (2) remove the pieces of code that were covered by those patents, and also (3) find prior art that would render the patent useless."

So in reality, a business decision to use ASP.NET means a business decision to run on Windows.

As far as scaling and all that fun stuff, I just have to point to Yahoo!.

I don't necessarily agree with the Oracle article; after all, it's Oracle trying to make non-Microsoft products sound better.

And finally, as far as the "benchmark test" is concerned: Yes, I too can make PHP code slower than ASP code if I choose to do certain things that any professional PHP coder would know not to do. In posting a benchmark, make sure your code is correct.
# July 26, 2004 12:00 PM

kmcafee said:

I just wanted to say that I work in a development house where there are 3 programmers in one division doing PHP web development, and 5 programmers in my team doing ASP.NET web application (sold to customers to provide business functionality, not hosting web sites) devleopment. We are very happy with the ASP.NET development experience for our needs. But PHP is also working out well for the other teams needs.

And the one MS point I totally and completely disagree with is the Accountability issue. Microsoft has 0 accountability, period. They have never stood up and taken responsibility for a problem, and they have never provided solutions at the same speed as any other business organization I have done business with. There are numerous bugs in Visual Studio 2003, and a handfull we found in the .NET library itself - all of which we discovered in our first 6 months of working with the technology, and reported to our MS Partner contact. Nothing has or will be done about any of them, period. Until they are fixed in whichever future release Microsoft feels like fixing them in.

How bout this one, use "devenv" to build a solution, and then open the solution with devenv visually (visual studio), and you cannot open ANY of the visual designers, you must "touch" these files first, or delete your web cache and or object files.

And if a SQL Server or .NET update ever looses my customers data, Microsoft will not offer me one bit of accountability, nor money to make reparations - they are as accountable to me as my congressman - which is to say, not at all.
# July 26, 2004 2:29 PM

Luis Alberto said:

I work for a small company. We have two servers running, one for ASP.NET (Win2003 and so) devel and the other is a LAMP machine (Debian Woody). Both servers work just fine, have almost the same hardware and run many apps, apart from devel ones.

The win2k+3 machine is maintained by an outsourcing company, that is an official partner of MS (cannot say names, we still work with them and I know that MS boys are going to throw shit on them) and, among other things, did Exchange, firewall and A/V thingies. It was a busy server, running also file and printing jobs for the whole domain on wich we operate, and a powerful one (like the other one): 2xXeon 2 GHz, 1 GB of RAM, some scsi raid storing.

I know that all that tasks are excessive for such a server, having in mind that we do ASP on it. So we purchased another server, a clone of this (they're IBM beasts) and installed Linux Debian on it, to use it as a PHP devel platform. As we work with Exchange, we moved the routing, firewalling, A/V and antispam to the debian machine, so the win server didn't have to maintain the load our internet use demand. This solution worked beautifully, but it was not sufficient. File and printing serving is a heavy task on our office, so we moved to Samba and Cups with excellent results. We noticed also that we could move the two scanners and share them with SANE on the debian machine.

Now, we can develop comfortably on the windows machine but look at this:
-Win2003 services:
-Exchange (~1000 processed emails per day), managing connections only from the debian machine.
-ASP.NET (two simultaneous users testing code, an occasional customer trying its work in progress web).
-DAT nightly backup, so it does not interfere with our normal ASP work). We are going to move this service to the debian server on september, as soon as I end trying a new backup system on an old PC running also debian.
-Domain controller, 16 users and 19 computers.

-Debian:
-Spamassassin + ClamAV + Postfix (as gateway for exchange, processing ~2000 emails a day, half of them are SPAM or virii from the outside and do not pass to Exchange).
-Apache 1.3.x, PHP 4.1.x, Turck MMCache
-MySQL 3.x
-Samba, 9 users doing some heavy tasks as editing large graphics files directly from the server. Four PHP developers, although their disk usage would be like 0.001% of the total being the rest used by designers.
-CUPS, serving a parallel kyocera laser printer and two USB hp deskjet printers.
-SANE, serving one HP flat scanner and a nikon diapo scanner (both USB).

Cannot give you any numbers, since these are production servers and cannot run any tests on them. But I can assure you that we are very surprised with the perfomance of the linux server, but also with the lack of perfomance of the windows server. The Linux server is bigger, so the comparison is not clear (2xXeon 2.2 GHz, the memory is also a bit faster but they have the same amount), but it runs many services on it and it's very secure. Usualy we have Exchange and IIS fighting for RAM, so the system gets very swappy, and I cannot imagine why IIS wants so many memory... it's not our app, we make some finetunning on it from time to time, and before doing anything we make some diagnostics on it, including the measuring of its memory footprint, which usually is what we expect (ok, we have some memory leaks from time to time which are resolved when detected).

I am really curious on a real benchmark, not MS/Oracle FUD or some user doing silly tests. First, because curiosity, and on a more professional side I want to know if the behaviour of the windows server is normal. An mostly idle webserver and a not very busy mail exchanger is not what I would expect to get a good server on its knees.

Anyway, we are moving all services to debian (converting the windows server) slowly, the current debian server is beggining to have too much responsibilities and I want to be able to transfer quickly and efficiently tasks from one server to another in case of hardware failure.
# July 26, 2004 3:51 PM

Bertrand Le Roy said:

DevNull: ASP.NET being maintained by one company is seen by some companies as an advantage in terms of consistency and accountability. If for you, "openness" is more important than anything else, sure, go ahead and use PHP, or... Mono.
As for "i guess its a lot more restrictbie and un-flexiable than PHP", well, guess again, this is just a gratuitous affirmation that would need a little more argumentation...

Toast: do some research. Here's what I could find in two minutes:
http://sourceforge.net/projects/nfop/ one of the open-source PDF libraries for .NET
http://sourceforge.net/projects/ming-sharp/ a .NET wrapper around the Ming SWF library.
And of course, as I was saying in the article, image creation libraries are built-in the .NET class library, as well as database access, etc. The main difference with PHP being that it's consistent, well-organized and object-oriented.

Richard: I'm well aware that other error treatment is necessary in the code you will substitute for "#work with the file". The problem here with the original code was that it throws and catches untyped exceptions, and it throws unecessarily, which is very bad practice.
Another problem that I did not underline in the article is that existing PHP libraries having been written before the support for exceptions appeared in PHP5, chances are that these libraries will not throw exceptions anytime soon and you will have to use different techniques for error treatment whether you use older or newer libraries. More inconsistency...

Nofool: you'll need a little more argumentation than that not to be taken for a common troll.

"Doesn't matter", whatever your name is: you're so clever, but you could also have read the article where I make it very clear that I work for Microsoft.

Caruccio: ASP.NET only takes the /proportion/ of memory that you configure in machine.config. It does not "eat up" memory, it uses what you configure there. There's nothing shocking there: the machine is supposed to be a web server, right? So the web process takes /available/ memory and uses it. So what?
1GB is more than enough, I've run dozens of web sites on 512MB machines without a glitch. Did you see the price of memory chips by the way?
The bottom line is does your web site run smoothly or not? The proportion of memory the web process uses is just irrelevant as long as it does not get in the way of other necessary processes.

Dick: you're right, I should perhaps have compared on the same time frame instead of just on the last version of each product. But you can do so yourself and you will see that it doesn't change much: over the time IIS6 has been on the market, there have been many more security issues with LAMP than with IIS+ASP.NET.

GPF: I did not quote the facts page as "proof", and if you have a better study of TCO for Windows and Linux, let me know.
As for your answer to Shaffer, well, I was personnally not talking about classic ASP. Actually, even I, despite all my pro-MS bias and my general dislike of the PHP syntax, would probably choose PHP over classic ASP. But fortunately, classic ASP has been replaced by ASP.NET. So this is just irrelevant to the current discussion.

Yeehaw: yes, it is perfectly possible to write more or less clean code in PHP (or classic ASP). I've written such code myself. But you really have to get out of your way to do so: linear models such as PHP promote spaghetti intertwined HTML and code, whereas ASP.NET promotes a clean separation from the start as the default model.
I'm glad you continued to read the article despite the fact that you stopped reading it (?!).
You know, your comment about IIS security is just disarming. You're accepting the common preconceived idea that IIS is unsecure despite all evidence to the contrary even when faced with this evidence. All you have to do is follow a single link or do your own research, but I guess you don't want to do even that simple thing because that would endanger your whole system of belief that MS is inherently bad.
And I guess that no, we don't live on the same planet.
Sure, many companies build great and clean things with open-source tools, I've never said or written anything that would indicate otherwise. I sincerely think that ASP.NET IS far superior to PHP, though, and I'm willing to show how.
Who said that you had to "marry" MS, though? Not me, just you. And what "bunch of cash" are you talking about?
You guys are way too irrational and should think more about productivity, maintainability, interoperability, you name it, stuff that really matters, not whether or not the producer of this or that technology is ideologically acceptable.

Jason: I never said that PHP could not scale. You're right in saying that Yahoo did this successfully. ASP.NET scales out of the box. The gratuitous affirmations to the contrary in the Oracle paper would have to be backed by some kind of study. Saying something does not make it true. Proving it does.
I agree that the "benchmark" Pzykoman posted in his comment do not mean much. I'm still waiting for a serious, real-world application based performance study.

Kmcafee: I'm very surprised by what you're saying about support. The experience I've had with them before I joined MS is completely different. Did you go through support for these? How did they close the events? Won't fix??
What are these "numerous bugs"? Were they aknowledged as real bugs?
The repro for the bug you cite is incomplete: I've been doing this kind of very simple manipulation every day for years and never encoutered or heard about having to touch the file. What did support say about this one?
About SQL or ".NET update" (what's that?), /did it/ lose some of your customers data?

Luis: you should contact support: I think there may have been some memory issues with the interaction of Exchange and ASP.NET. It should work, though, even though it's generally not a good idea to put both on the same servers (I can hear the zealots already. Well, in my former company, we had Linux machines and we did not put mail servers and web servers on the same machines on Linux either)
# July 26, 2004 4:20 PM

TrackBack said:

The article on ActiveWin
# July 26, 2004 4:22 PM

TrackBack said:

This promises to bring more comments than I can reasonably handle. Oh well!
# July 26, 2004 4:26 PM

Bruce said:

Nice article, rebutting a laughable original. However I couldn't help noticing that every mention of ASP.NET etc points to the relevant Microsoft sites, but you didn't put a similar link even on the first mention of PHP or Oracle. A nit that spoilt my impression of the article!
# July 26, 2004 4:53 PM

Oscar Leeper said:

Bruce:

Take a look at the comment you just posted. Did you add links to Microsoft and ASP.NET? I sure didn't add them to mine.
# July 26, 2004 5:45 PM

Bertrand Le Roy said:

Bruce: the ASP.NET and Microsoft links are automatically added by the .text engine. I could add the same kind of automatic links for PHP and Oracle, but then I would also have to do it for every other company out there I may mention the name of. I won't as the blog's focus is ASP.NET...
But here are the addresses of PHP and Oracle anyway:
PHP: http://www.php.net/
Oracle: http://www.oracle.com/
# July 26, 2004 5:52 PM

Jason Lotito said:

Bertrand: My comment regarding scalability was in response to another comment I read on here (I believe). As a PHP programmer, obviously my opinions should be taken with a grain of salt.

However, what I have found is that professional PHP programmers are more than willing to admire .NET for it's strengths. ASP.NET unforunately has the tradition of ASP via VB (which, frankly, sucked). ASP.NET is an improvement, and there are efforts in the PHP Community to take what we find nice about ASP.NET and implement it for PHP.

For example, the "Widge Control" functionality of ASP.NET has been done in PHP with different libraries. WACT is a fine example of this. On a side note: PHP has a fine history of taking what is nice in other languages and using it. PHP's support for external libraries is amazing (and frankly, that's it's purpose, to be a glue language). Anyways, off topic...

As far as Oracle's paper: Yeah, for those that know better, it's Oracle's way of biting at MS's ASP.NET. ASP.NET and PHP are competing technologies despite the underlying architecture, as is Java and C#. So if you are Oracle, and you want to diss ASP.NET, which technology are you going to talk up, will it be Java or PHP?

PHP, of course!

Frankly, articles like these serve the readers little, as you have to question the reason for putting out an article like this. Granted, MS's own ASP v.s. PHP article wasn't any better, but any developer worth his salt could see that a mile away.

Frankly, I am happy and successful with what I do, and as long as ASP.NET continues to move forward, it will only force us PHP guys to make sure we compete. Competition is good, after all. It will only make PHP and ASP.NET better in the long haul.
# July 26, 2004 6:36 PM

Bertrand Le Roy said:

Jason: Thanks for the message. Yes, competition is good, and the PHP market shares are a strong motivation for us. I'll have a look at WACT, which I don't know.
# July 26, 2004 6:40 PM

Another matthew said:

Hi from OSNews.com :)

"[embeding code in html] This is true of PHP, but not of ASP.NET, where the code can, but /should/ not be in the HTML markup"

In practice, this means that ASP.NET has a built in templating language whereas PHP doesn't -- and that's all. It's not about which of the many abstraction and templating layers in both languages are best -- an XML/XSLT approach or an OO controls model for example -- it's just defaults. ASP.NET's default templating language has code at the top as a reference to the code behind (and you can't have two of these, I think) so one could argue the binding in ASP.NET is similar too. Similar, unless you choose otherwise and use a templating language that outputs your markup. The supposed mixing of code and content exists in both languages.

The biggest mark against ASP.NET is that it's not cross-platform (Mono doesn't count yet ;), and that for any web standards nazi the HTML it produces favours MSIE over others.

Sure, you can choose controls that produce good html, but ASP.NET doesn't by default ;)

Good response though. I generally agree with you, but just because the Oracle guy isn't a good programmer doesn't mean a thing to PHP itself.

Thanks!
# July 26, 2004 7:10 PM

Bertrand Le Roy said:

Other Matt: It's not just templating. What about the rich page lifecycle? What about events? What about WebControls?
By the way, ASP.NET 2.0 will produce standard XHTML out-of-the box by default.
# July 26, 2004 7:14 PM

TrackBack said:

Nexen reprend la news d'OsNews
# July 26, 2004 7:57 PM

TrackBack said:

Some commentaries on Channel9
# July 26, 2004 8:00 PM

Another matthew said:

"It's not just templating. What about the rich page lifecycle? What about events? What about WebControls?"

Bertrand Le Roy: I've been writing C#/ASP.NET for 2 years now, but I'm coming to prefer a hybrid ASP.NET/placeholder/XML/XSLT approach to page generation. The page lifecycle is... well, it's actually got in my way a lot of the time. It's useful for application start and stop, and I guess it's breaks up the code into their order.

I would have loved for ASP.NET to have a placeholder control that maintains state for it's added controls. There's a 3rd party control that does this, but last time I checked (6 months ago) it was buggy as hell.

As I was kinda hinting, my main complaint with ASP.NET is that it's an abstraction away from http, html, and the vagaries of web browser bugs. The problem is that the browser bugs exist, so you can either ignore them (ASP.NET style) or deal with the underlying tech. When you've got two search forms on a page ASP.NET puts them as a single form tag, so pressing enter submits both. There are hacks that use javascript to hit the right button based on which field you're in but it's a workaround, and it doesn't degrade gracefully for older browsers. I develop government websites so there are requirements around this kind of thing -- we can't rely on Javascript. JoelOnSoftware called this a leaky abstraction or something like that -- when it'd be nice to tell programmers that you can deal with onClick and onChange events on a per field/button basis, but that the nature of the web means otherwise.

PHP has a library called PHP Web Controls (a ripoff of ASP.NET's model).

ASP.NET is pretty good, but I prefer the XML/XSLT approach and capturing the actual form elements as POST/GET rather than an abstraction. Now that I've got my abstraction library (a week to write) ontop of ASP.NET it doesn't take longer than the buggy event model.

XHTML in ASP.NET 2.0 will be great.
# July 26, 2004 11:42 PM

TrackBack said:

It's been a while since I have looked at any PHP so I am unable to offer any lucid commentary regarding the ASP.NET vs. PHP debate (originally sponsored by Oracle and Sean Hull) currently taking place on Bertrand Le Roy's blog ("Some co
# July 27, 2004 12:21 AM

TrackBack said:

iamwill » Oracle’s comparison of PHP and ASP.NET; The comments keep rolling in.
# July 27, 2004 2:44 AM

Warren said:

The author is wrong with his outdated knowledge of PHP.

PHP is still the better tool. It's more flexiable and has more functions.

The author is wrong to assume that PHP ALSO is best used seperated from the HTML, it has a include_once (as well as an include) function, which is usually used to bring in the PHP library code.

PHP is also more portable and follows a C++ style (less typing) format, not some beginners style of basic that ASP follows. every time I use ASP I have to drop my intelligence to MS level.

I too have used both ASP and PHP, on windows and Linux. Overall PHP is better by far!

# July 27, 2004 9:00 AM

Bertrand Le Roy said:

Another Matt: It's true that you need to know the page lifecycle to do things in the right order, otherwise it can get in the way. But when you come to think about it, that's what makes all the magic stuff in ASP.NET possible (automatic state management, events, etc.). I think we've simplified the writing of ASP.NET pages in Whidbey a lot, even though the lifecycle is now even richer.
I assume you mean to maintain the state of dynamically added controls. The WebParts and their zones do that in Whidbey, but a more general purpose control could be interesting. I'll look into it.
We've also made things better in v2 for multiple form problems. You can now have default buttons, and have a button post to a different page, while retaining the strongly typed experience of ASP.NET.
I think the web is getting more mature now, and ASP.NET, especially with the new Adapter infrastructure, is the only web platform that is able to automatically adapt to the peculiarities and bugs of each browser or device. After all, hardware abstraction has been working pretty well in OSs, so why would browser abstraction and HTML abstraction be a bad idea? It certainly works in ASP.NET. There are some cases where you can feel that using the old Request.Form may be easier, but that can be a slippery slope, and you may end up rewriting a part of the framework where you could probably have done the same while maintaining the ASP.NET model intact. I don't know about your special case, it would have to be looked into in details. I know that I've made this mistake in the very beginning of ASP.NET (classic ASP methods were hard to loose) and discovered later that my problem had a much simpler and cleaner solution.
But you know, we shouldn't impose our own idea of how you should develop, and I'm very glad that you found your own method and that it works for you. I even think that PHP is what works for some people just because they like this style of free-form, I control exactly everything, style of programming. I even know some people who love to develop in assembly language (I used to be one of them).
So we have to allow for different styles.
By the way, can you be a little more explicit about the "buggy event model"? What's buggy about it? If you found bugs, I'd like to know about them so that we can correct them. By the way, we opened this site to submit bugs and suggestions for Whidbey:
http://lab.msdn.microsoft.com/productfeedback/

Mattia, Warren, etc.: if you have nothing more constructive to say than "your article suckz, php rulez, MS suckz", please go away.

In particular, Warren, it's amusing that you should tell me my knowledge of PHP is outdated as you yourself are talking about classic ASP, not ASP.NET. Come on, PHP follows a C++ style?? Are you kidding me? A Perl style, ok, but not C++. C# follows a C++ style (C#, you know, one of the languages you can CHOOSE in ASP.NET)
And separation through include_once? Wow, take a look at ASP.NET's Register directive. It's just light years ahead.

Bob: of course, you dropped the main part of the citation, which was that individual cases should not be taken for generalities. I'm only talking about verifiable things, you guys are talking about purely emotional things. I also said that we still had a lot of work to do, but of course, you didn't want to hear that, you only hear what conforts your system of beliefs.
Just compare the number of security issues in IIS 5 and IIS6 and see how much progress we've made in just a few years on this huge code base. We're doing the same kind of work on Windows itself, and this will give XP SP2 and Longhorn.

Anona: please do your homework before you post such preposterous nonsense. Open a web browser, go to Google, type "mac worm", click on the search button with your single-button mouse and click on the first thing that shows in the many answers:
http://securityresponse.symantec.com/avcenter/venc/data/mac.simpsons@mm.html
Oh, it's a worm, and it's for the Mac.
Of course, a worm for MacOS won't get very far as there are so few macs. Like a virus that would target people with Vayron eyes.
Why are there anti-viruses for the Mac by the way?
I also did a search on Apple Mac OSX Server on http://www.securityfocus.com/bid/vendor/ and there are just too many vulnerabilities for me to bother counting. Do the same search on Windows Server 2003: there are 2.
Of course I'm not denying that there have been a lot of problems, but like Bob, you don't want to listen to what I'm saying.
Get me right this time: I'm not denying. What I'm saying is that we've already made a lot of progress (see the numbers for yourself: the record speaks for itself indeed) and that we're still working.
You're saying that we haven't done "much" to solve security problems? How do you explain the numbers on security focus then?
Get real. Get the facts.
And go away.
# July 27, 2004 2:19 PM

TrackBack said:

# July 27, 2004 2:56 PM

Bertrand Le Roy said:

Dear trolls,

This is not your private chat room. This is my blog.
With your uninteresting, unoriginal rants, you're making this page heavier than it needs to be and wasting legitimate reader's bandwidth.

So here's what we're going to do. You're going to open your own blog, and rant all you want there. I'll even trackback to it if it's funny enough.

In the meantime, I'm moving all trollesque comments to this page from now on:
http://weblogs.asp.net/bleroy/articles/199077.aspx
# July 27, 2004 5:51 PM

Bysza said:

Anona: I understand you're a Mac power-user, right?
That is great. :)

How much did you pay for your Mac?
I'm not claiming to be a Mac expert, but I took a time to lookup a Mac like this:
Bundle Power Mac G5 2.0GHz DP 512 160 4x SuperDrive 56K NIC w 1GB Upgrade - lowest price: $2339.00 (without monitor)

Opposed to: Dell Dimension 8400
Pentium® 4 Processor 530 with HT Technology (3GHz, 800 FSB)
Microsoft® Windows® XP Home Edition
512MB Dual Channel DDR2 SDRAM at 400MHz (2x256M) at $989.00 (with monitor).
Correct me if I'm wrong, but AFIK these are at least comparable machines, right?
Unfortunately with uncomparable prices. :(

We have lots of PCs in our company (1000+) and several Macs. Well, I bothered to ask my collegues working on them about problem they had.
Mac is and was advertised as a problem-free computer, which is not entirely true.We had problems with several hardware items, including SCSI drives, scanners, etc.
MacOS has its faults, bugs and also security problems.
Every part is 2 or 3 times more expensive than PC hardware, but at least Mac box looks great. ;)

How many directly Internet connected Macs are there?
Do you have any idea?

First of all, during early stages of Internet era, say late 80' and early 90', how many network connected hosts there were?
Did everyone was thinking about security as much as today?
Look on TCP/IP. It has no security features and ability to easly spoof addresses is causing lots of problems. Same with SMTP, etc.
And of course the idea to build IE as an integral part of the OS... ;)

It is a big problem (or impossible ;) to upgrade every internet connected windows boxes to the newest os or at least install patches on each, especially when there are no features build in the older windows versions that could allow that.
And people are not keen on upgrading, since lots of them doesn't know what is going on with their machines.
They just want to play games, browse internet and read mail. That's where the biggest problem lays.

It is a challenge to change thousands of employees mindset and correct so huge codebase as MS has, especially when you think of the compatibility with vast amounts of applications already written for this platform.
I'm really satisfied with progress MS has done so far in terms of security out of the box and I'm looking forward to WinXP SP2.
But I'm not saying that it shouldn't be done earlier ;)

My point is:
If you are satisfied with your Mac - use it and be happy. :)
Security is a big concern for a few years now, and MS has invested in security a lot of efford and money.
Implicity and explicity admitting security is a major concern.

Please let go the holly war, and give peace a chance... :D
# July 27, 2004 6:57 PM

TrackBack said:

# July 27, 2004 8:51 PM

Another matthew said:

Bertrand, yes I was talking about maintaining the state of added controls. Steping back though, the only reason to add controls to a page and register events with addHandler() -- all that hassle -- is because that's the way the ASP.NET event/page lifecycle/OO model works. Other models wouldn't require this, so I think I'm being fair when I say that ASP.NET still has a way to go (it's good, but it could be a lot better).

Many platforms adapt to the device they're on, so I think it's overstating it to say that ASP.NET is unique in this regard (hundreds of CMSs do browser detection and produce different output based on this; whether it's a simple template change or by using high-level objects that adapt their HTML to the browser).

I agree that a high-level object model expressing abstracts like "treeview" and "tabs" that is then turned into device-specific html is the best -- that's a good approach, however ASP.NET turns asp:panels into div tags for IE and table tags for Moz! Their radiobuttonlists are produced with label tags surrounding the text and not the radio button, which would be better for Konq and NN4 (with no downside). The abstraction that ASP.NET provides is used to produce HTML that works better in IE. This is just talking about defaults again, but it's a little annoying to have to write repeater controls to get the appropriate HTML. Even required fields (as in, the required field validator in ASP.NET) is poorly implemented in non-IE browsers, and it allows non-IE browsers to bypass this step.

I assume you've read the JoelOnSoftware article about leaky abstractions -- my point is that ASP.NET is a leaky abstraction. HTML and HTTP don't have the concept of required form fields, and they don't have a way of distinguishing between hitting enter in a form and which button is affected (if any). ASP.NET and many platforms build ontop of HTML higher concepts such as treeviews and tabs and buttons -- they build abstraction, but if abstraction is done poorly it can be confusing to programmers.

Now, I don't want to end this post on such high concepts, because they tend to blur the different possible approaches within each concept. ASP.NET could have done required form fields transparently for all browsers but it didn't. This isn't a general statement saying that abstractions mean losing control (because of course it means that) but the abstraction must be well done or else it leaks, and ASP.NET (and others) leak.
Thanks :)
# July 27, 2004 10:26 PM

Julien Ellie said:

Haha :) Bertrand you're crazy to have taken down this ridicule article from Oracle and you're now fighting hordes of troll. Luckilly there're still a few interesting comments in there from people who have a little respect for people trying to do their job.
# July 28, 2004 3:08 AM

Bertrand Le Roy said:

A.Matt: I don't really understand what you're saying about dynamic controls. Actually, there are very few good reasons to add controls to a page dynamically, I'd need to know your precise use case to give any advice.
But I'd be curious to see how other models solve this problem. I don't know any other framework that do. But perhaps I didn't understand exactly what you were referring to.
I take your points on non-IE browsers, this is something we should do better, even though we always have a fallback. For example, validators are always enforced server-side (as they should be even for IE to prevent elementary forged posts), so you just get an additional postback on these browsers. But agreed, there is no good reason (except the limited time we have) to not implement client-side validators for DOM-compliant browsers.
On the other hand, there are some third party validators that solve this problem. After all, our job is not to give every possible control out of the box, but to provide a web development framework on which you can build your applications. We try to solve the most common scenarios out of the box, but we can't do everything at once. That's why there is a v2, and that's why there will be a v3. There's always room for improvement and your feedback is valuable.
And if I'm not mistaken, you don't have this issue with validators on PHP because there are no validators, so you actually have to build them from scratch.
I've read the JoelOnSoftware article, and his main point seems to be "the abstractions save us time working, but they don't save us time learning". Fair enough, but you still save time working. And granted, to do ASP.NET well, you probably need to learn a few things like the page lifecycle.
But one of the things he does not mention, though (or perhaps I missed it), is that the learning can be very progressive. I think ASP.NET is good for beginners because you don't have to learn HTML and the other underlying concepts first (like in PHP), you can start with the high-level concepts. In my own experience, it is very common with what Joel calls "leaky abstractions" to only have to learn the underlying complexity along the way (the later the better). For example, after all these years writing C# code intensively, I still know very little IL (and only because I was curious about it, not because I really nedded it).
Thanks for the feedback anyway, it's refreshing after all this reckless trolling.
# July 28, 2004 1:51 PM

PLeX said:

Thought this was quite funny...

Poll results from bottom of Oracle article:

Created :Wed Jul 28 15:56:29 PDT 2004 Please rate this document:
Excellent 1541 Votes 18.8%
Good 1085 Votes 13.2%
Average 292 Votes 3.6%
Below Average 2563 Votes 31.2%
Poor 2721 Votes 33.2%
Total: 8202 votes
# July 28, 2004 6:57 PM

TrackBack said:

Yexley
# July 28, 2004 8:58 PM

TrackBack said:

# July 30, 2004 1:23 PM

TrackBack said:

# August 4, 2004 2:45 AM

Siva Mateti said:

Why not use Server.Transfer instead of Response.Redirect especially if both pages are aspx? How can I avoid ThreadAbortException for Server.Transfer?
# August 4, 2004 9:22 AM

Bertrand Le Roy said:

Excellent question.
Server.Transfer will not get the right URL in the address line of the user's browser. If that's acceptable, you can use Transfer, and you save one client/server roundtrip.
Now, Transfer also has a Response.End (and hence a ThreadAbortException), but the code inside Transfer is really just two lines:
Execute(path, null, preserveForm);
Response.End();

So you see that to avoid the exception for Transfer, you should just use Execute instead.
Of course, if you do that, you still need to suppress the output from the first page because both pages will output to the same response (you don't need to do that with Redirect because you have two separate requests in this case, and thus two different responses, the first one being thrown away). This can be done by clearing the response before calling Execute or doing some funny stuff with the writer parameter of Execute. Many strange scenarios here ;)
# August 4, 2004 1:19 PM

TrackBack said:

# August 5, 2004 3:09 AM

Siva Mateti said:

# August 5, 2004 8:55 AM

TrackBack said:

# August 5, 2004 2:00 PM

Dimitri Glazkov said:

I am not sure that it has to be an ideal world for the clean separation to work. Indeed, the concept needs refinement, but the core of it is good, methinks. Imagine something like this: an adapter pattern with decoratorish tendencies applied to rendering of a control.

This way, a control only represents the data and manipulation with it. It does not emit any markup, but it does know how to retrieve, process, and update information.

Parallel to it is an adapter, which doesn't know how to do any of the above with the data, but it does know how to query control's properties and how to render it using markup.

Yes, this means that for each control there has to be an adapter, but it is a compromise that we ought to be willing to make in order to escape hard-coding HTML into control's functionality.

We are essentially continuing the Page Controller paradigm into the controls, rather than stopping at the level of the page.

As a possible implementation scenario, an adapter could simply spit out control's properties as XML and allow developers write XSLT to transform it into HTML.

You could also easily imagine an adaptive control, which attempts to render properties of any control -- this is not necessarily a production environment-type trick, but something that could be useful to render orphan controls -- those without a corresponding adapter.

This is why my third role is for advanced developers -- creating adapters would not be something that a designer would do. Following requirements of a designer, yes, but probably not a designer him/herself.
# August 5, 2004 5:00 PM

TrackBack said:

# August 5, 2004 5:13 PM

TrackBack said:

# August 5, 2004 5:13 PM

Bertrand Le Roy said:

I understand your points, but one of the places where the whole thing falls apart is performance. This is what I mean when I say it's an ideal world, something we should tend to, but that we should not place above everything else, despite having to solve the real-world problem in all its complexity.
Believe me, this approach where adapters are completely separated from the control has been considered, but unfortunately, adapters are expensive. As would be to have an additional XML/XSLT level.
The choice that was made is to make is as efficient as possible for the main scenario (which is HTML) and fall back to adapters only when we need to.
If you look at the present state of things, the rendering is already pretty much separated from the rest of the control: you output HTML only in Render.
Where I don't agree with you, even from an idealistic point of vue, is in your core analysis that controls should be some kind of local page controller only, leaving the rendering to some other entity. While I agree that there is a benefit in having ways to override this part of the control's behavior (as well as others), most controls are UI elements first, not data manipulating entities (exceptions are non-visual controls like DataSources and these do not render anything). The purpose of a control as I understand it is to transform some part of your data into markup AND to manage the interaction of the user back with this data (which is what XSLTs don't do).
So I think if your control does too much data manipulation, that's a sure sign that part of this code should be in a different layer and not in your control.
Don't forget also that a control's interaction with the user is dependant on the actual markup. It's a two-way thing.
So what would be left in a control if it doesn't do the rendering (and thus can't do some of the interaction either) and doesn't do stuff that belongs in other layers? Almost nothing, it's then just a structure. You've just added a useless abstraction, transferring all of the logic into the adapter.
# August 5, 2004 6:29 PM

Bertrand Le Roy said:

Brant, can you elaborate? Millions of developers successfully build UIs with HTML and ASP.NET or some other server platform. How are they "failing at some point"?
I agree that XAML solves many of the problems we have to face with HTML, but HTML is very far from being the dead-end you're talking about.
# August 5, 2004 9:20 PM

Dimitri Glazkov said:

Bertrand, I think your assertion that most controls are UI elements is correct and valid. There are a couple of "buts" though:

1. There is definitely a trend into making controls more than that -- look at the "login" control in Whidbey, for example. For all I can see, it's a little self-contained application.

2. Being a UI element doesn't mean that controls have to emit the actual markup. That is why I am advocating a layer of abstraction -- to provide capability to translate UI into whatever flavor of markup (even XAML, perhaps?) is required.

3. The mentioned above layer of abstraction has to work both ways -- in fact, it should be the purpose of translating results back and forth. The control doesn't need to worry about whether this was a POST request, a GET request, or an asynchronous WS callback of some sort. The control doesn't need to worry about how it would be rendered. All it has to do is to advertise to the rendering layer that it will take a one-line input of plain text titled "Login", a one-line masked input of plain text titled "Password", and a "Login" button. The control performs validation and reaction to the input. The rendering layer makes it look "pretty". I am simplifying, of course.

I realize that what I am proposing is veering off from the current concept of a Web control, but hey, that's what this communication thing is for -- thought generation :)

As far as performance is concerned, I understand your point. Balancing functionality and performance is a tough act. I do believe, however, that there are ways to minimize impact of an abstraction layer on overall application performance. You guys wrote a book on this stuff :)
# August 6, 2004 9:18 AM

Bertrand Le Roy said:

Brant:

HTML is much more than RTF because of two things: Javascript and the posting mechanism. Yes, its semantics are those of a document markup language (it comes from SGML after all), because the people who conceived it couldn't foresee the importance the web would have today. But it has been improved and is today something you just can't avoid.

Of course, Windows Forms, XUL and XAML (and others) are more suited to interactive applications than HTML is. And if you have a choice, most applications should be written using a smart client technology. But you rarely have this option, even though the deployment problems are more or less solved. So there is a strong need for technologies like ASP.NET and there will still be for some more time. Of course you won't develop Excel in ASP.NET, but you can and you have to develop applications such as Outlook Web Access, which is very close to the desktop application. If only because when I'm away from my office, I still need a way to consult my mail from any computer I may find. And the only reasonable way you can develop this kind of rich application for the web is by adding a level of abstraction like what ASP.NET provides with WebControls.

I wish we all lived in a world where you don't need to develop for HTML but can always use something richer, but this is not the world we're living in. It's great to develop better rich client technologies. I see you contributed to Mozilla and XUL, this is great, but don't fall into this trap: you don't have a universal answer that applies to everything (by the way, the subtitle of my blog is highly sarcastic: ASP.NET is no universal answer).

By the way, which ASP.NET Tree control are you talking about? There are many such controls. The one we're shipping with Whidbey (and the only one we're supporting) DOES support Gecko browsers. It even does out-of-band node population without posting the whole page thanks to the excellent implementation of XmlHttp that Gecko has.

I'm a little confused also when you talk about "pixel perfect" layout. In my mind, pixel-perfect is more needed in printable document formats such as PDF, but certainly not in applications. Accessibility constraints, for example, are one reason why your UI framework should be able to gracefully adapt to very big fonts. There goes pixel-perfect layout.
Actually, all recent UI frameworks allow for dynamic resizing and positioning of the elements according to some general and relative layout.
And of course, HTML has always allowed for this by default, which makes it notoriously unprintable, but highly adaptable.

Dimitri:
I think I agree with you on the whole principle, and I think we're trying to get there, but we have to integrate our own constraints (which are huge because of our enormous developer audience). We make tradeoffs every day, we have to.
But if you read this recent article: http://www.theserverside.net/articles/showarticle.tss?id=AssemblyVersioning you can probably spot a few hints about what transformations there will be in the structure of ASP.NET in v.Next.

About the login example, yes, there is some functionality in the control, but it's still just managing the interaction of the user with the underlying authentication layer. I see what you mean, though, and it's an interesting idea.
I think we're already addressing most of this concern, though.
For example, templating is one way you can take the relevant part of the rendering to the page (or user control).
Adapters are also another way you can do that.
Themes are also very powerful (though not many people realised how much).

The main thing is that the additional layer is completely optional. The default basic scenario stays performant because it does not have these additional layers. We're trying to make the optional scenarios performant too, but there's no way they can ever be as fast as the default behavior. And believe me, we spend a lot of time on the optimization of this stuff (adapters were tough for that matter).
# August 6, 2004 2:35 PM

Bertrand Le Roy said:

By the way, I love it when the comments become larger than the original message. It proves that the subject was well chosen :)
# August 6, 2004 2:36 PM

TrackBack said:

I'm a fan of Nikhil's blog and this one is a great post. Read it!
# August 7, 2004 1:45 AM

Bertrand Le Roy said:

From Nikhil's post: "A key problem with adapters is exposing internal state of the control to the adapter. It is possible to expose some state, but the moment an external developer decides to write a new adapter, it is likely they will find they need some piece of internal state information that has not been exposed to them. The adapter model essentially creates a parallel inheritance hierarchy, which doesn't work all that great for extensibility in the long run."
# August 9, 2004 3:31 PM

Eric said:

I have several business layer components I have created that I don't want in the flow design but would like to have in the tray where the SQL Connection object and others go. The only way I have been able to accomplish this is to inherit from System.ComponentModel.Component - BUT, being that I am not inheriting from System.Web.UI.WebControl all my state management, etc is gone. I need to inherit from System.Web.UI.WebControl but still have the control be put in the tray or not be visible. I tried "marking" the control with the [NonVisualControl] attribute but it just says "The type or namespace name 'NonVisualControl' could not be found (are you missing a using directive or an assembly reference?)
"

Any suggestions? In case anyone is wondering...the control manages the routing of documents for approval.

Here is the start of one of my control declarations:

[NonVisualControl, DefaultProperty("Department"), ToolboxData("<{0}:ApprovalFlow runat=server></{0}:ApprovalFlow>"),]

public class ApprovalFlow: System.Web.UI.WebControls.WebControl
# August 10, 2004 2:16 PM

Bertrand Le Roy said:

NonVisualControlAttribute is new in ASP.NET v2.
The tray is gone too in v2. In v1, the designer would mess a lot more with your code, and would represent on the design surface objects that are really declared in the codebehind (in the infamous "do not touch" sections).
In v2, the designer only changes what is in the declarative part of the page (that is the markup), leaving what's in the codebehind entirely your business.
So in v2, your code will still run, but I don't think you'll see your components on the design surface. Except if you make them non-visual controls and put them in the markup. They will still be in the design flow, but you can hide them using "hide non visual controls".
# August 10, 2004 2:33 PM

Greg Holmes said:

MS seems to have a problem with this "hey, we're hip, we're listening; we have blogs!" thing. The individual developers seem to have pretty thin skin ;)

If you have a blog, a real blog, then discussion is going to ensue. In public. Much of it rough and tumble. That's kind of the point of tech blogs.

# August 17, 2004 2:41 PM

Bertrand Le Roy said:

Greg: not at all, the troll comments are very public, and I did not delete a single message. You just have to follow the link if you really want to read all that nonsense.
I just think that the immense majority of readers has other things to do than read troll posts. The trolling on this article was drowning the few relevant comments, and making the page unnecessarily heavy. I just took the irrelevant comments out of the page, but did NOT delete them. So it's still public, and you can very well post your comments there.
# August 17, 2004 2:46 PM

Jeff said:

I cranked this out in old fashioned ASCII text last month:

http://weblogs.asp.net/jeff/archive/2004/07/04/172683.aspx
# August 17, 2004 3:47 PM

mike said:

Here's a link to an entry that describes the effect of ValidateRequest:

http://www.mikepope.com/blog/DisplayBlog.aspx?permalink=441
# August 18, 2004 10:10 PM

Jerry Pisk said:

Well, it would all be lot easier if Microsoft would stop bowing to beginners and actually encourage secure coding. For example, Struts' form input or message server tags HTML encode their output by default and you have to turn it off if you want to, while ASP.NET's input, literal and other tags do not provide HTML encoding at all. If you want it you have to add server side code to call Server.HtmlEncode().
# August 18, 2004 11:42 PM

shartzog said:

trackback
# August 19, 2004 12:14 AM

TrackBack said:

learn about injection attacks!
# August 19, 2004 12:49 AM

TrackBack said:

# August 19, 2004 1:07 AM

George V. Reilly said:

"Writing Secure Code" has a lot to say about all of this, and should be a must-read book for all developers.
# August 19, 2004 2:54 AM

Mike Griggs said:

Great article, thanks.
# August 19, 2004 6:21 AM

TrackBack said:

# August 19, 2004 6:43 AM

Kyle Heon said:

There is a way that you can pass a string of comma-seperated values (numeric in the case of "Rule #4: Use parametrized queries whenever possible."). I have been using a user-defined functions (SQL2000) that I found from www.sqlteam.com years ago.

It can now be found here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsqlmag01/html/TreatYourself.asp

This is a very powerful function because it has allowed me to continue disabling read/write access the user and only granting execute rights to the stored procedures.
# August 19, 2004 7:21 AM

Brant Gurganus said:

I was at a job last year as an intern and I seemed to be the only one that cared about these things. My coworkers claimed that average joe user wouldn't do these things. I tried to argue that it isn't average joe user you need to worry about.

Besides the obvious means of input such as input controls, make sure URL parameters are cleaned as well as cookie data and hidden form fields. Average joe wouldn't change those things, but somebody with knowhow and malicious intent would. In the case of URL parameters, some browsers such as Mozilla allow you to create keyword-invoked bookmarks that replace the a '%s' in the bookmark URL with the text after the keyword when typed in the URL bar.
# August 19, 2004 9:18 AM

g said:

I tried to used the

Response.Redirect("~/default.aspx", false);

on a normal ASP page and get "Wrong number of arguments or invalid property assignment"

Is there a solution for the same problem in a non- .net environment?
# August 19, 2004 10:53 AM

John S. said:

Excellent write up.
# August 19, 2004 10:57 AM

Ron Buckton said:

I have some pointers for avoiding injection attacks in two common instances, 1) Passing arrays to SQL Server and 2) advanced search queries (e.g. avoiding WHERE clause concatenation) at:

http://blogs.chroniclesdesign.com/rbuckton/archive/2004/08/19/145.aspx
# August 19, 2004 11:48 AM

Bertrand Le Roy said:

Jerry, this is simply wrong. If you had just tried this: <asp:textbox runat=server Text="<script>alert('blah');</script>"/>, this is the rendered html you would have got: <input name="ctl00" type="text" value="&lt;script>alert('blah');&lt;/script>" />
We do not encode literal controls because they are... literal.
# August 19, 2004 2:03 PM

Bertrand Le Roy said:

g: This version of Redirect only exists in ASP.NET, not in classic ASP. There is no such thing as an exception in classic ASP, so you actually don't have this problem at all as far as I know, so no need to solve it ;) But I may be wrong. It's been such a long time since I've done any classic ASP at all.
# August 19, 2004 2:13 PM

TrackBack said:

# August 19, 2004 2:46 PM

TrackBack said:

# August 19, 2004 2:48 PM

TrackBack said:

blog.jasonnussbaum.com :: Flash, Programming, and Everything
# August 19, 2004 2:53 PM

TrackBack said:

Bertrand Le Roy has an excellent introduction to injection attacks. If you're doing web development and don't know what an injection attack is or how to prevent them, you have got to read this....
# August 19, 2004 6:24 PM

mike said:

Jerry Pisk, you seem to be contradicting yourself, if I understand correctly. On the one hand you say "stop bowing to beginners and encourage secure coding" and on the other hand you say "Struts ... encode their output." I interpret this to mean that Struts doesn't encourage secure coding either -- it's all just done automatically. (?) As Bertrand notes later, asp:textbox does encode, although the more secure option (on by default) is to reject potentially bad input in the first place. Precisely because so few people understand the need (or techniques) for encoding -- see other comments -- the default behavior of ASP.NET is to enforce security for you.

FWIW, auto encoding for controls like asp:label breaks the otherwise legitimate ability to included formatted markup as the Text property for that control. Ditto Literal, of course.
# August 19, 2004 10:26 PM

John D said:

Wow, some of us don't have the luxury of arguing all day long about an internet article. I will take whatever someone gives me in the way of business. I do PHP at work, I do ASP.NET at home, the new job I'm applying for *might* go to JSP, and I use Classic ASP for the Portland Access User's Group (www.PAUG.com). Am I going to convince someone to change? I doubt it. I'm a lowsy salesman. And I can't hold my own when it comes to was/wasnot rattatattat. What I got out of this whole blog (and it is a lot, mind you) was the need to go back and study typing so I too can type fast.
# August 20, 2004 12:58 PM

TrackBack said:

# August 20, 2004 11:10 PM

TrackBack said:

# August 22, 2004 1:17 PM

TrackBack said:

Matt Berther
# August 23, 2004 3:31 PM

JP.Boomtown | spIder said:

Thanks for the article!
# August 26, 2004 2:30 AM

Mike Griggs said:

C# starts to look more and more like C++/STL with every passing day...
# August 31, 2004 5:29 PM

Wesner Moise said:

For more concisely is to use the following iterator method

IEnumerable<T> FilteredEnumerable<T>(IEnumerable<T> en, Predicate<T> pred)
{
foreach(T t in en)
if ( pred(t) )
yield return t;
}

# August 31, 2004 5:36 PM

TrackBack said:

# September 1, 2004 1:35 AM

TrackBack said:

# September 1, 2004 1:36 AM

TrackBack said:

# September 1, 2004 2:52 AM

TrackBack said:

# September 1, 2004 2:54 AM

TrackBack said:

Great post about iterators.
# September 1, 2004 8:07 PM

Accessibility said:

I don't know if this will ever be read, but...

Bertrand, I don't think you, or anyone at Microsoft, for that matter, understands that HTML is just a structural markup, and does not - in fact, *MUST* not have ANYTHING to do with how the data is displayed.

In general, HTML must be written such that Netscape 1.0 (the one from 1994. or so) displays it properly, fully and completely, as well as IE6 (which should be dead) and Opera 7.x, Safari, something based on the Gecko engine, _plus_ Lynx and Links.

There are people who have disabled JavaScript. They can't do much on ASP.NET pages. There are also vision-impaired and blind people, and the story is the same because ASP.NET are mostly random tag soup, instead of a structured and valid HTML document...

The purpose of adapters should not be to fall-back functionally to older and different browsers, but to ENHANCE the *APPEARANCE* for newer ones.

There's no excuse AT ALL to do XMLHTTP requests to populate tree nodes in a tree control. None whatsoever! Someone who loads a page for offline use will get screwed by this, and will get screwed royally. The ONLY proper thing is to create a good old structure of nested unnumbered lists COMPLETELY and have JavaScript-enabled visual browsers take care of node expanding/collapsing.
# September 2, 2004 5:18 AM

Bertrand Le Roy said:

Dear anonymous strict guy,

Thank you for assuming everyone at Microsoft is an idiot. What you say is more or less true of HTML + CSS, which not all browsers understand, but absolutely false for pure HTML. Take the <b> tag, for example. Why is it in every version of HTML including XHTML? It's not structural, it just means bold text, which is pure form. And it's not as if you couldn't do a span with a class that has bold font-weight. So why is it still there? Just because there are the extremists who think everyone should work the way they have decided is the right way, and there are the pragmatic people who think some freedom is better than any dogma, however "perfect" it may be.

It is absolutely correct to assume that a web site should be browsable with Lynx and when Javascript is disabled, as well as by people with disabilities. You can build such pages with ASP.NET 1.1 (which does not mean that everyone does it, most people don't bother). Now, with ASP.NET 2.0, out of the box, you'll get XHTML compliant code and accessibility by default.
And when you build a web site, having ways to achieve everything without javascript does not mean you have to force this on everyone and not have quicker ways to achieve the same things when javascript is enabled.

The purpose of adapters is to adapt the markup for _marginal_ situations. The default behavior should go to the most common situations. This is so obvious I'm appalled by your statement.

Now about XMLHTTP. First, you seem to forget that the web is not just a collection of documents. There are applications out there, for which offline use is simply meaningless. By the way, offline browsing is a very very marginal thing and will become even more so.
Now, take a site like MSDN. Hundreds of thousands of articles. Would you really like the treeview to preload all the nodes so that you can browse it offline or with a text browser? This is completely unrealistic as your page would take forever to download. The right approach is of course to adapt to a link list that can take you to the next level and that enables you to navigate back up one level (à la Mac Finder as opposed to the Windows explorer tree).
And there are of course all kinds of applications that need treeviews that are filled as nodes are open. Posting back the whole page is a waste of bandwidth, that's why the XMLHTTP mechanism is there. By the way, this is not the default behavior of our TreeView.
Actually, this is quite funny as this is one of the features that gets the most positive feedback from the community.

You know, I also get feedback all the time from people who have decided there is one and only one way to write a web page. They will tell you for example that menus should only be written using CSS and no javascript. CSS menus are great technical achievements, but they can't be keyboard accessible, for example. Ours is.
Accessibility is an absolute requirement for ASP.NET 2.0 and you can rest assured that all of our controls will be accessible by default, including TreeView and Menu.
# September 2, 2004 2:09 PM

Robin Debreuil said:

Hey Bertrand,

Thanks for the 'way too kind' review. I must say that I wasn't able to accurately describe my feelings toward the whole exercise, but "impressively time consuming" is exactly perfect. In fact that is the one phrase that describes pretty much everything I've been passionate about in my life -- and I always thought these things were unrealted. That would certainly have to be the major text in any bioctal proficiency diploma. Oh, and it would make a hell of a blog sub title!

That is a great idea on the balanced ternary bioctal numbers, it really opens up a lot of possibilities. I've been experimenting with a system where bits are like charges (+/-). There are two digits, making four states +1, -1, 0 (neither), and an impossible set of both (which always destroys itself leaving 0). In certain ways Zero makes more sense not being a digit, at least it always seems a bit awkward the way its used now. With 'charges', negative and positive numbers are written the same, just they use different 'digits' (eg Int32 and Int64 represent negatives the same way, no confusion between -1 and 0xFFFF, etc..). Adding a positive to a negative can result in a 'mixed' number after the cancellations (a number with both +1 and -1 digits), but the normalizing is pleasantly simple. It also gives bool states of (something like) True (1), False (-1), NotTested (0), and Impossible(+-). Hmm, I can never describe these things in words, esp when having my end of day wine. I'm doing some animations I'll post...

Anyway, after reading your idea about ternary bioctal numbers, I've been trying tonight to get the above system into positive and negative larger numbers. It becomes pretty interesting, this really makes you ask a lot of totally basic questions about the nature of the numbers. Using two colors works for writing, but obviously there would need to be a logical way to represent positives vs negatives without color, and also zero and (+-)... What do you think would be a the right base for a system that goes naturally above and below zero (like ternary also does)? Would it be -8 to +8, or -16 to +16? I really like the symmetry of 4^4 (and 3^3 in ternary), just not sure if that should be half on each side of zero, or a full negative mirrored copy..

Anyway, I think that last glass of wine has rinsed out the day's caffeine, so time to sleep. Btw, your blog has been the first good and deep overview of Whidbey I've read -- looks like it really will be something else, cool even : ). Thanks for that too...

Salut,
Robin

PS Do you really think the solar system would be that much more boring without my anus? Creepy.
# September 4, 2004 6:02 AM

Bertrand Le Roy said:

Well, Robin, not my idea, it came from a comment on your blog. After that, it was just adding nevi and minus nevi.
Actually, I might give you a few hints that you may find useful or not, dating back from my thesis work, which was about graded algebras, with a focus on ternary algebras. Perhaps you know of Grassmann algebras, which are non-commutitive Z2-graded algebras, for example. Here, it looks like you're building a graded algebra but can't find the right grading group. See the sign as the grade, and the grading group is then Z2. Now, zero does not belong in the grading group, but in the algebra (otherwise, your grading group is no longer a group because it has no neutral element). What's the grade/sign of zero? You decide (the folks who designed the way signed integers are coded in binary decided it was positive).
Seems like you have some more useless thinking to do.
By the way, did you consider publishing your stuff in a scientific paper, something not too academic like Scientific American? It would be great fun to see this in a mainstream journal.

Do you realize that thanks to you, when you type "Microsoft butthole anus" in Google, chances are you'll end up on my blog? Thanks a lot, really.
# September 7, 2004 2:53 PM

Robin Debreuil said:

Hey Bertrand,

Thanks for the pointers to Grassmann algebras, that looks like totally fascinating stuff. Yes huge amounts of useless reading ahead, happy to say. Still it will pale in comparison to the massive amounts of time you must have consumed doing a thesis on the subject. I can only stand in awe.

I would love to publish something in a magazine like Scientific American, even a letter, but it's always seemed so out of reach. Recently though, I've become more hopeful... I'm not trying to brag here, but I've been offered pretty generous funding for my next article. It titled, "New Numeric Writing System Disproves Global Warming". Of course the required travel and research will soak up most of that, but it is still a small step towards the dream...

Btw, sounds like you could make some serious coin with google ads ; ).

Cheers,
Robin

PS - Completely unrelated, but with ASP.NET I've recently found a few servers I admin have backups of config files, called web.config.old or something. Being that these were generally artifacts left over from early testing, they sometimes contained unencrypted passwords, or db access stuff. The problem of course is they could be downloaded from the net. Obviously that is a user error, but maybe it would be a good idea to block files with the pattern ".config" (appearing anywhere) by default? Just a thought..

# September 8, 2004 2:14 AM

Bertrand Le Roy said:

Just try it. If you've got good material like your stuff, it's probably easier than it seems.

About the old config file, use the web.old.config name instead of web.config.old. That will take care of it as the .config extension is never served.

I'll think about the Google ads, thanks for the tip.
# September 8, 2004 1:27 PM

www.atomic9.net said:

It would be nice if a standards group (or Microsoft-based equivalent) created a standard regex library of whitelist/blacklist patterns to handle input. That would make a great first-layer of defense against SQL injection attacks.
# September 9, 2004 10:57 AM

Bertrand Le Roy said:

Not sure why you think this should be a standard, but you can find a lot of such regular expressions on sites such as regexplib.com.
The problem is that there would be about as many expressions as there are use cases. If you try to do something too universal, there is a serious risk to have too many false positives and to block legitimate data. The white list is often very context sensitive. I've showed an example on integer fields, which is one of the simplest cases, but it can get a lot more complicated than that.
The point is that to fight against SQL injections, the best you can do is always use parametrized queries. This way, you never even need white lists.
The cases where you can't use parametrized queries are very few.
# September 9, 2004 2:16 PM

mike said:

We still need the opposite, the late, lamented DataSetDataSource that turns XML data into relational data. :-( Bind a GridView to an XML file? No problem!
# September 11, 2004 5:36 PM

TrackBack said:

Bernard discusses a new Whidbey data source control that he's developed that allows you to use relational data hierarchically. This is pretty cool; it allows you to use the logically hierarchical structure of a relational database in hierarchical contr ...
# September 12, 2004 2:24 AM

Jack said:

Because it is usefull
# September 16, 2004 2:11 PM

Keith said:

Well said! Well said! I particularly HATE the F Lock key!
# September 16, 2004 2:11 PM

Kevin said:

WOW I am having the exact same problem with 'PrintScrn'

WHY MS WHY
# September 16, 2004 2:12 PM

Bertrand Le Roy said:

Jack: I'm really genuinely interested. What is the Num Lock key useful for?
# September 16, 2004 2:17 PM

Matt Hawley said:

I hate it too, but its useful for users who don't know the shortcut keys Ctrl + P is print.
# September 16, 2004 2:18 PM

Eric Newton said:

my issue is why doesnt Print Screen actually PRINT THE SCREEN...

I dont see a key on my keyboard that says COPY SCREEN TO CLIPBOARD SO YOU HAVE TO PASTE IN PAINT THEN YOU CAN PRINT SCREEN key...

I dont even think they could fit all that onto a half inch square key...

Die, F Lock!
# September 16, 2004 2:54 PM

Matthew W. Jackson said:

What's with the new delete key, too? Why can't you get a normal keyboard anymore?
# September 16, 2004 2:57 PM

Shane Courtrille said:

Death to the F key. My keyboard has this and I hate it with a passion. If it wasn't off by default I would hate it a little less but the hate would still be there... Anyone know of a good non-MS natural keyboard?
# September 16, 2004 3:05 PM

James said:

I strongly dislike the way that many keyboards do not have the same placement of important keys, such as the backslash, which can either be placed above or below the return key, or the delete and insert keys which can either be placed above the cursor keys or at the top-right-hand corner of the keyboard on many laptops... At least use the same general layout!

On laptops, the NumLock key is important because they don't have number pads, so it allows you to use certain keys on the main keyboard as a number pad... but because of the way many laptop keyboards are laid out, this is not always useful either.

James.
# September 16, 2004 3:16 PM

John Drake said:

Keys I have never seen any use for are the Scroll Lock key and the Pause / Break key.

Has anyone ever had anything useful happen by pressing those keys?

Anyhow, this is about the NumLock key. I use it. Most times it is turned off, because I tend to use the keypad for navigation. I will occaisonaly turn it on if I need to do extended number entry.

John
# September 16, 2004 3:19 PM

Bertrand Le Roy said:

James: of course it's useful on laptops, and should be kept on these devices, but on ordinary large keyboards that have a real numeric pad, it's totally useless. By the way, Num Lock on a laptop does not have the exact same meaning as the numeric pad is not separated and thus the keys it replaces are not the same.
In other words, Num Lock on desktop duplicates keys that we already have (and is off by default, although Windows now retains its state on reboots) whereas on laptops, it replaces other unique keys.
# September 16, 2004 3:20 PM

Bertrand Le Roy said:

John: I think this is really interesting. I'd like to understand why you use the numeric pad for navigation instead of the dedicated arrow keys just next to it?
# September 16, 2004 3:23 PM

Frans Bouma said:

The only key I really hated (that's past tense indeed) was the caps lock key. I used a keyboard remapper tool to map it to cntrl :) I'm not sure but perhaps you can remap numlock as well :)
# September 16, 2004 3:31 PM

petal said:

you think that's annoying? try working regularly with a keyboard that doesn't have a keypad (instead uses the mjkluio789 keys for 0123456789 respectively), and which supports multiple servers - switching between screens using a KVM switch can often leave you wondering why the hell your account is getting locked out when you *know* you've got the password right - all because the numlock status varies from server to server! I fail to see why this needs to happen when there is a perfectly serviceable numeric row at the top of the keyboard. Thank god for registry settings.
# September 16, 2004 3:32 PM

anonymous said:

Scroll Lock can be used in Excel. Try it and arrow around on the spreadsheet :)
# September 16, 2004 3:36 PM

Anonymous Coward said:

I use the numeric keypad for number entry and for navigation, frobbing NumLock as required.

I do this because I've been doing it for the last twenty years, because it works for me, and because I have better things to do with my time than retrain my brain to use this week's arrow-key-location fad.
# September 16, 2004 3:37 PM

Bertrand Le Roy said:

Anonymous coward: that kind of makes sense, but you must be really as pissed as I am about F Lock, then. And about the new layout of keyboards as a whole.
At the same time, I've used computers for about 25 years and I've seen so many different keyboard layouts during that time that I really don't think the old IBM keyboard layout is deeply imprinted into my brain to the point where it would take me a substantial amount of time to change my habits.
I'm sure you can still buy keyboards with the old layout, which would make it reasonable to forget about the errors of the past and have truly good keyboards that don't put themselves in unusable states all the time.
# September 16, 2004 3:42 PM

Jerry Pisk said:

If you use the numeric pad for one feature and only occasionaly switch to the other you can just use the Shift key (i.e. if your Numlock is off then num keys with Shift will type in numbers).

You can use the Pause/Break key to pause some games and if you hold down the Win key and hit Pause/Break you will get System Properties (which I use to start Device Manager when I need it).
# September 16, 2004 3:44 PM

tuthils said:

John, I use the pause and break buttons quite fequently within command prompts. Ctrl-Break is still used in ping to display statistics without actually halting the process and it also responds to pause, though I'm not sure there is a whole ton of use for that.

In any case, I whole-heartedly support the anti-F-lock key movement and if I could just get it turned off by default, the f@#$ing thing could be ripped from my keyboard and placed on my monitor as another decoration. Not once in the 6 months I've had the keyboard has that key been useful, and it is a real pain toggling F-Lock to use PrintScn then having to switch F-Lock back as I'm more accustomed to Shift+Ins for paste than Ctrl+v (holdover from my QuickBasic days). Granted, I can use both but my hands just naturally go for shift+ins when I go to paste.

Coming from the world of the Commodore 64, it took me a long time to get used to the fact that to go left with your cursor you did not have to hold shift and hit right. Brains can be retrained for new keyboard layouts but it's a bugger during the retraining phase.

My $0.02 USD.
# September 16, 2004 4:00 PM

Patrick said:

I got a new Microsoft wireless keyboard, and it's great except that HORRIBLE F-Lock key. As a programmer, this is the most annoying hardware device I've ever seen. Every reboot, I have to remember to turn this thing back on so that I can use my F-keys like I'm used to in Visual Studio.Net.

Horrible idea.
# September 16, 2004 4:34 PM

Florian said:

Absolutely agree !!! Moreover, it's impossible to unlock F keys on starting even with the keyboard driver (Natural Multimedia keyboard). Otherwise, i'm lucky my numpad is always unlocked :).
# September 16, 2004 4:55 PM

Alex said:

the F-lock key really pisses me off.

it wouldn't be so bad if the default operation enables the function keys!!!

who was the genius that decided the function keys should be subbordinated to the "new" keys. now people who actually learned all _original_ shortcuts have to remember to press the F-key before they start any work. pretty dumb.

ok so now you've pressed the F-key and all your shortcuts work. you can Alt-F4 with impunity

hmm, i need to get to the System properties really quickly. no prob, just hit Winkey + Brk key.

uh oh! someone skimped on a button. gotta turn of the F-key before that shortcut works.

lame!
# September 16, 2004 5:26 PM

Ben Constable said:

I learnt how to type on an Amstrad keyboard that had no directional keys, and I had to joystick. So I learnt how to use directional keys on the numeric keyboard. If I want numbers I type them using the number keys.

I agree about F lock though. I keep meaning to search for a way to permanently leave it on.
# September 16, 2004 5:33 PM

Edward said:

It'd be nice if the Numlock status could be based on which usb-based keyboard you have attached. On my tablet PC having numlock on with the detachable keyboard remaps part of the alphabet, so I can't type my password in, but when it is attached to the docking station I use a full size keyboard with a numeric keypad and I like numlock to be on all the time since I use it to enter IP addresses etc.

Basically I want numlock ON when I have a numeric keypad available and OFF when I don't.

The only thing I use the Break key for is when running VB6 programs through the IDE. Pressing CTRL-BREAK causes it to break straight away.

I have an optical desktop elite so I have the dreaded F-Lock key. It truely is useless and annoying, it wouldn't be so bad if it could be controlled through software like num-lock, but since it is not a real key and merely a hardware setting you always have to remember to turn it off every time you start up the computer.
I've never used scroll-lock for anything, except now it is the same key as break I keep pressing it when I don't know if F-Lock is on or not.
# September 16, 2004 5:45 PM

Geoff Appleby said:

I definately hate the flock key, but love my ms natural keyboard. I don't mind how the home/end keys etc were rearranged (took me a long while to get used to tho).

The first thing i did when when i got a keyboard with the flock was to go here and download the inverter:
http://www.mvps.org/jtsang/flock.html

It reverses the keystates, so that with flock OFF it's F1, and flock ON it's help, etc.

However, this is a permanent change, and if you plug in a keyboard that doesn't have flock, then your fkeys won't work (they'll send the otehr keys).

Hope this helps some of you, because it sure helps me :)
# September 16, 2004 7:01 PM

Bertrand Le Roy said:

Thank you, Geoff, and thank you Jason Tsang! This is great!
# September 16, 2004 7:03 PM

Barry Dorrans said:

Ah numlock. What a pain on notebooks, when Windows decides that it's a good idea to have numlock on after boot. When you don't notice. And get locked out of your account because you have a letter in your password that corresponds to the numeric keypad embedded in your laptop keyboard.

Note that you can fix this, with a registry edit

If you go to HKEY_USERS\.DEFAULT\Control Panel\Keyboard the flags in IntialKeyboardIndicators control the intial state of num lock, caps lock and scroll lock after boot.

0 - All off
1 - Caps Lock on
2 - Num Lock on
3 - Caps Lock on and Num Lock on
4 - Scroll Lock on
5 - Caps Lock on and Scroll Lock on
6 - Num Lock on and Scroll Lock on
7 - Caps Lock on, Num Lock on, and Scroll Lock on
# September 16, 2004 7:47 PM

TrackBack said:

The dreaded FLock key.
# September 16, 2004 10:32 PM

Jeff Parker said:

DEATH TO THE FLOCK KEY Just to chime in, god I hate that thanks though to the links to keep them permanently off.

No one has seemed to mention my other absolute hate The one I hate so much anytime I see a keyboard with it I take it apart and inject silicon in between the contacts under the rubber mat. A Shut down key. Seen these stupid things a key on your keyboard you press and your computer starts shutting down right away. After the 3rd time I lost a crap load of work by accidentally hitting the shut down key is when I started using silicon to completely disable that key permanently. I mean do people really need a shut down to be a simple keypress they can't click Start and shutdown, what it takes too much time?
# September 17, 2004 8:49 AM

Bertrand Le Roy said:

What all of this feedback seems to indicate (other than the universal hate for the F Lock key) is that we need a harware or software switch to permanently set the state of some of the keys (namely, F Lock, Num Lock and shut down/sleep).

Oh, by the way, who hates sticky keys too?
# September 17, 2004 1:36 PM

Roland Weigelt said:

I could live very well with a keyboard without the arrow keys and the other keys between main part of the keyboard and the number pad ;-) I prefer navigation on the number pad; when I rest my middle finger on the "5" key, I can reach all the keys I need by moving only my fingers.
If I use the arrow keys and the 6 keys above, I have to move the whole hand, which is much less efficient when editing text (or am I just using the keys the wrong way?) And when using the numeric keypad, I can use more fingers of my right hand (e.g. thumb, small finger). Also, I have a couple of macros for expanding/collapsing regions assigned to the numeric + and - keys.
I must admit that I never use the number pad for actually entering numbers. Maybe it's because I rarely need to enter numbers, or maybe because the key layout is different from that of a phone.
# September 17, 2004 5:54 PM

tuthils said:

Sticky keys just today caused me plenty of heartache and grief as I struggled to find out why as I was unlocking my computer my password would not work, knowing Caps Lock was not the culprit (tried it both ways)!

Since I'm complaining on about the accessibility features: I really dislike having holding Shift both disable AutoPlay for inserted CDs and to enable FilterKeys. Maybe I just let up too early or maybe I'm naive and Shift isn't the key you're supposed to hold at all to prevent AutoPlay but for me every time I've tried holding Shift to disable AutoPlay, the filterkeys screen comes up and the CD is run anyway.

I am not against the accessibility options at all, I know there are people out there with legitimate uses and I personally rely on MouseKeys when I'm in our data center at the KVM console as for some reason the mouse isn't responding anymore.

I guess I just have never looked close enough, I just found out those shortcuts (pressing shift 8 times for StickyKeys and holding shift for 5 seconds for FilterKeys) can be disabled! In any case, I'm still no fan of StickyKeys :-)

Back to the F-Lock key, I'm a software guy, not hardware so please forgive the simplicity of this question but would it be possible to just run to the local Radio Shack, pick up a tiny toggle switch, and somehow solder it into the F-Lock key (well, its contacts) and kind of... force... it's state one way or another? I'm sure that voids any warranty but I'm willing to forgo that warranty for the option of not having F-Lock on anymore.

Maybe someone in Microsoft's product design labs will see this great dislike of that key and produce an F-Lock free keyboard. I love the idea of the reverse mapping, but being on a laptop, I have to have my F keys away from the docking station as well :(

The rest of my keyboard is great and it's amazing how often I've used the Calculator key as opposed to hitting Win+R, type calc and hit enter. (Not a huge mouse fan either)

It's great to see so many people share my feelings on the F-Lock key though :)
# September 17, 2004 6:19 PM

jinath said:

good info
# September 18, 2004 1:10 AM

lowercase josh said:

What web browsers don't support png? That is, among those used by more than four people worldwide on a daily basis?

And the number of colors is more important than just for palette size. It reduces the "alphabet" that exists in the image data, making compression more effective.

Dithered images *are* harder to compress. Ordered/pattern dithered images less so, but they'll still end up bigger than no dithering.

You should use interlacing on large gif or png images. Some people still connect at 56k, and sometimes your server gets overloaded. If your image is large enough to matter, the slight increase in file size won't matter, but you should probably consider using jpeg or css instead.
# September 18, 2004 4:27 AM

Hal said:

You might wanna talk to the paint.net guys so then this article could be a demonstration of MS technologies too. :)

http://www.eecs.wsu.edu/~cs423/423spring04/Team2/
# September 18, 2004 9:05 AM

Dimitri Glazkov said:

Excellent. We need something like this as an MSDN article. Will you take me as a co-author? :)

A couple of things I would add:

1) It takes practice and developing a good eye to get the dithering and color optimization right. Spend some time playing with your first images -- it will pay off later on.

2) Photoshop versions 7.0 and CS have some color optimization built-in -- they will attempt to automatically come up with the minimal number needed to render the image, but the algorithms are not very aggressive (which is a good thing), so for complex, photo-realistic color images, the optimization doesn't get very far. It does, however, work really well for the simple-pallette images.

3) In my experience, the only Dither algorithm that is really useful is "Diffusion" when used with gradients. "Pattern" looks horrible on pretty much anything Web-related and "Noise" usually looks worse than "Diffusion" and adds a lot of weight to the file size. Like Bertrand said, there's rarely a reason to monkey with Dither quantity -- just leave it always on 100%.

4) If you are doing graphics, ask your boss to let you have both LCD and CRT monitors on your desk. It also helps to have more than one of each to check on (see my workplace for a slightly exaggerated example: http://glazkov.com/blog/archive/2004/06/19/195.aspx). Colors, especially slight variations, typically look more pronounced on an LCD panel.
# September 18, 2004 9:13 PM

Bertrand Le Roy said:

Josh: you're right, most browsers that are used today understand PNG. But for us, "most" is just not enough, we need all. But for your day to day web design needs, you're right, PNG can now be used pretty safely (and it has the advantage of not being restricted by patents). I agree 100% with your other comments, in particular on the fact that if your image is large, you should consider JPG.

Hal: Paint.NET is not really MS technology, it's a student project. It's pretty nice (i use it too sometimes) but still has a long way to go to compete against Photoshop. Then again, it's free, which is a really nice feature.
The MS imaging product is Digital Image Suite, which has amazing features, but is not targeted at professionals. It is more oriented towards familial users. I use it at home to fix my photos.
Anyway, the reason I used Photoshop in my tutorial is that it is by far the imaging product that's the most used by professional web developers.

Dimitri: OK for the MSDN article. Send me mail so that we can arrange that.
# September 19, 2004 2:27 AM

Bertrand Le Roy said:

One thing I had not thought about and that could explain why I use the numeric pad so much, and why native english speakers don't is that on french keyboards, you have to use shift to access the numbers on the main part of the keyboard. It makes the numeric pad a necessity much more than on a qwerty keyboard.
I guess that makes the num lock key much more annoying for people who have learned to type on azerty and similar keyboards.
# September 20, 2004 1:59 AM

Rob Cannon said:

It's a great facility. The only problem is that I would like to see a solution that will also work for non ASP.NET project. Shouldn't this be something that can be harnessed by Visual Studio/MSBuild (or is it already)?
# September 22, 2004 9:28 AM

Robin Debreuil said:

I had a natural keyboard knock off once, it had all remapped arrow/home/etc keys -- and right beside the left ctrl key was the sleep button. No kidding. So I actually one day unplugged this and smashed it against the floor, repeatedly. In my hunt for a new natural keyboard (I was overseas and couldn't get an ms or logitec one) I found a second brand. It had all normal mappings it seemed, however when I checked for the 'sleep beside undo' problem I noticed, and this is no joke, I may still have a photo -- the power off key.

Obviously that keyboard designer has moved up in the world, and now we have FLock. The worst part of that is the logic probably went, "if we allow people to disable it, then everyone will and no one will get used to my wonderful feature". If it was for the sake of new users, I hope they convinced the software side to rewrite all the help docs that say "press F1 for Help", etc. Terminally stupid.


# September 22, 2004 11:23 PM

dimitri.glazkov@gmail.com (Dimitri Glazkov) said:

Ah, technology vs. human, the age-old battle.

How's that article coming? :)
# October 6, 2004 10:54 AM

BillT said:

I agree with Rob. (I still do more WinForms that ASP.NET apps with VS 1.1.)
I'm not sure how you'd do this. (a) Perhaps just an API call to initiate the necessary examination and processing of the (or any) directory. (b) Perhaps a project (shipped with VS) that would be added to a solution. This project would implement all the needed processing.
# October 8, 2004 4:44 AM

Paul Wilson said:

Love it -- thanks for the post.
# October 8, 2004 5:20 AM

Bored programmer said:

Wonderful explanation of a very difficult concept! Very good, my friend.
# October 8, 2004 10:41 AM

Bertrand Le Roy said:

It's a great question. Though I don't have a precise answer right now, this new feature of ASP.NET is just a build manager that you can easily configure.
ASP.NET is very different from Windows Forms in that it is a server environment that has to compile on-the-fly. I suppose that in a Windows Forms application, the need to do it on-the-fly is much less important. The same thing could be done at application launch. I suppose MSBuild could be used for that, but I don't think you need it. It should be enough to look at the config, scan any registered directory in there and launch the declared build providers if a recent enough dll does not already exist. Then load the dlls and... voilà.
Actually, this would make a beautiful project if someone wants to do it...
# October 8, 2004 1:18 PM

Robin Debreuil said:

I really enjoyed that. The fact that it was (or wasn't) my destiny to enjoy it doesn't diminish the pleasure either.

# October 9, 2004 6:57 AM

preppy said:

AllGreek and Latin to me!!!!
# October 18, 2004 9:37 AM

TrackBack said:

And it IS considerably more verbose, though quite elegant thanks to delegates. Thanks, Sebastien!
# October 18, 2004 6:57 PM

TrackBack said:

# October 21, 2004 8:09 PM

TrackBack said:

# October 21, 2004 9:34 PM

TrackBack said:

# October 27, 2004 12:23 AM

haacked@yahoo.com (haacked) said:

I'd make one counter argument to this, though I agree with you for the most part. I wouldn't be opposed to a web framework in which controls could access certain properties of the page.

Bat only through a known interface and if the control degrades gracefully if the Page class didn't support the interface.

For example (inside the control):

IFrameworkPage specialPage = Page as IFrameworkPage;
if(specialPage != null)
//... Access properties of the page specific to this framework
else
//... degrade gracefully
# November 17, 2004 11:11 PM

mike said:

One reason to expose properties on the page is if you want to access them after a Server.Transfer, or in Whidbey, after a cross-post. However, I forget whether those have to be public. Also, I suppose, a reason that people do that is to get access to control properties that are children of the page.
# November 18, 2004 1:12 AM

TrackBack said:

# November 18, 2004 3:02 AM

TrackBack said:

# November 18, 2004 3:03 AM

Bertrand Le Roy said:

These are good points.
Mike's point is especially true, though I personnally don't like cross-page posting: even though we made great improvements in ASP.NET 2.0 in this area, I still think that when you go to a different page, there shouldn't be a strong coupling between both pages. And with the current mechanism, the target page relies on the source page inheriting from a special class or containing special controls. It's strongly coupled. I personally dislike this architecture and prefer to use weaker coupling such as querystring parameters when it's possible.
Mike's second point, though, is precisely what I'm arguing against, if I understood correctly.
# November 18, 2004 1:49 PM

mike said:

You understand correctly -- my point was only that I believe that people sometimes use public page properties to expose control values. (Such an example appears in the docs, I see.) I just checked, and it seems you can use FindControl on the page B to get values out of A -- it still (kind of) breaks encapsulation, since it requires the target page to know the ID of the control to get, but at least it doesn't also require the container page (page A) to add a property to expose the control value(s).
# November 18, 2004 5:54 PM

TrackBack said:

Here are two more great blog entries about preventing SQL Injection Attacks....
# November 29, 2004 10:55 PM

TrackBack said:

# November 30, 2004 9:23 AM

TrackBack said:

# November 30, 2004 9:26 AM

AndrewSeven said:

42...Second time I've seen that today. 6x9?


Abstractions leak, they must, if they didn't leak, they wouldn't be abstractions, they would be reality.

Abstractions are a special form of obfuscation, they hide the details that are not relevant to the "goal at hand".


The universe just is.
All our perceptions, all of our formulas; those are the abstrations.


http://weblogs.asp.net/andrewseven/articles/QuoteMe.aspx
# December 2, 2004 11:04 PM

Jeff Atwood said:

ASP.NET is *ULTRA* leaky though. Dynamically generated webforms almost always force me to peek under the covers, no matter how hard I try to stay abstracted. In some ways, it's the worst of both worlds: to get my work done, I have to fully understand the abstraction layer and all the plumbing underneath.

I acknowledge that it's a very difficult problem and ASP.NET is still much nicer than the alternatives, warts and all. I'm sure 2.0 will be even better!
# December 3, 2004 12:08 AM

haacked@yahoo.com (haacked) said:

That abstraction is the universe itself.
# December 3, 2004 1:07 AM

TrackBack said:

# December 3, 2004 10:46 AM

Brian said:

uh.. it's 6 x 7 not 6 x 9 :)

for the people who are complaining about abstraction, well.. how bout this, i'll start coding my web app in ASP.NET, and you just use binary. Let's see who get's there first. if you can manage it, I'm willing to bet your's would be faster. But, it will take you years to accomplish what I can get done in a week.
# December 3, 2004 2:25 PM

Bertrand Le Roy said:

Well, in base 13, 6x9=42.
# December 3, 2004 4:01 PM

TrackBack said:

# December 7, 2004 8:44 PM

Adi Oltean said:

Black hole evaporation is a real effect. The speed of evaporation is directly related with the mass of the black hole. Very small black holes are dying very quickly. Larger black holes have a much larger evaporation time. In general, the speed of evaporation is proportional with the cube of the black hole mass.

Here are more details on this subject:
http://en.wikipedia.org/wiki/Black_hole_evaporation



# December 14, 2004 8:52 PM

Bertrand Le Roy said:

Sure it's a real effect, but it sure isn't yet a fully understood phenomenon as it lies at the frontiers of quantum mechanics and general relativity, which, to say the least, don't mix well.
Thanks for the link, which is very informative and should give a basic understanding of the phenomenon to those who don't know about it.
An important piece of data in this article is the time it takes a black hole to evaporate. Black holes formed from a collapsed star seem to have no chance of disappearing anytime soon, or anytime at all. Only primordial black holes (formed at the same time as the universe) could evaporate in a reasonable amount of time. Furthermore, the article says that the equilibirum size for a black hole (where it absorbs as much as it emits) would have the mass of the Moon. Again, primordial black hole only. Unfortunately, no one knows if small primordial black holes exist. We have some clues about large primordial black holes, but so far not small ones, as far as I know.
Anyway, my main point was what happens really to a particle that plunges into an evaporating black hole? Does it enter the horizon at all?
# December 15, 2004 1:45 PM

Adi Oltean said:

>>> Only primordial black holes (formed at the same time as the universe) could evaporate in a reasonable amount of time.

This is not known yet.... At least in theory, small black holes are continously forming and dying quickly all the time. All you need is enough energy to "compress" matter in a very small area. Given enough energy, this is possible. It is suspected that cosmic rays (that have extremely high energies, above hundreds of MeV) can create these black holes. Fortunately, these black holes are dissapearing as quickly as they are created so there is no danger there.

See this link for more details: http://www.newscientist.com/article.ns?id=dn4446

>> Anyway, my main point was what happens really to a particle that plunges into an evaporating black hole? Does it enter the horizon at all?

Of course. There is nothing special about this horizon, except that anything that goes there cannot come back.

This might look weird, but it is not completely weird to have movement only in one direction in the four dimensional space-time. Actually, in space-time, this is a natural property of the time dimension - things are only moving one way, from past to future. With space dimensions, things can move both ways except in the case of black holes, when they move only in one direction.

# December 16, 2004 3:52 AM

Sigurdur G. Gunnarsson said:

Hi,

This is something that has been troubling me for awhile. While most of this sounds right to me, there are some things that I don't like.
I use quite a lot of custom reference types, and some are mutable. I use them in collections and want to be able to sort them. I do that by implementing IComparable and the collection classes sort them via that interface.
Well, the rules state that if you implement IComparable you must implement Equals and the operators ==, !=, < and >.
Doing all that I end up with reference types that don't match up with the rules you state.

Am I missing something?
# December 16, 2004 5:41 AM

Bertrand Le Roy said:

Adi, thanks again for the feedback. I didn't know that mini-black-hole could form so easily, I thought stellar and primordial were the only kinds. I guess my physics are a little outdated (I quit the field ten years ago). But now that I've read the article, it sure makes sense.
Now, on the second point, of course I'm not discussing the possibility that a particle can theoretically enter a classical horizon. I used to know General Relativity quite well having worked in a Cosmology laboratory during my PhD thesis so this is quite clear to me, no mystery there. The particle enters the horizon in finite time, we just perceive that it takes infinitely long and it's ok because our region of space-time is causally diconnected from the inside of the horizon so there's no paradox. What I'm talking about here is very different.
When a black hole evaporates, from our reference frame, we see incoming particles taking infinitely long to cross the horizon. At the same time, we see the horizon recess and finally disappear. So a logical conclusion seems to be that from our reference frame, we still see the particle after the black hole has disappeared, and it never entered the horizon.
But there is only one objective reality even in Relativity, so the only conclusion seems to be that the particle never enters the horizon. From the reference frame of the particle, what must happen is that events seem to happen faster and faster, including the recession of the horizon and its disappearance in finite time.
I think no particle ever enters the horizon of an evaporating black hole. Which gives a different answer to the information paradox. That's my point.
I'm very ready to be proven wrong, I'd be more than happy to: I'd learn something new, and I just love that.
# December 16, 2004 1:51 PM

Bertrand Le Roy said:

Sigurdur, that's a very good question. For value types, well, they should really be immutable anyway, but for reference types that must be IComparable, in short, for the moment, I don't know exactly. I've asked the question to some CLR gurus and I'm waiting for an answer. Stay tuned.
What I can recommend for the moment is that you base your implementations of IComparable, Equals and GetHashCode on immutable properties if you can (even if the rest of the type is not immutable).
As a last resort solution, if you don't need to use these types as keys in a hash table (which is the main reason to use the hash), you could throw from GetHashCode.
# December 16, 2004 2:15 PM

Adi Oltean said:

Oh, I see now your original point. Interesting problem...

So, let me dumbify a little the experiment so I can understand it... :-). A source of light is launched from some point outside of the black hole. The source approaches the event horizon and enters into it. From an external point of view, photons will be continuously detected with lower and lower energies.

Now here comes BH evaporation. At some detectable point in future (around t1 in the reference frame of the observer) the black hole completely evaporates. At this point in time (or around it) the source of the signal simply stops from the observer point of view. For sure, something happened with that source of light due to the interaction with the black hole. But I think that the end result should be that the observer must have NO way to determine whether the source already entered or not into the event horizon.

Anyway, all these are simply speculations which might or might not make any sense given that I am not familiar with the mathematics around this theory. Probably the event horizon becomes "special" when the black hole is near to its end of life and close to quantum dimensions? This special "fuzzy" event horizon will look like it is triggering other physical interactions which might cause the destruction of the source of light due to the black hole. And these interactions must also give the same end result to the observer as in the case when the source actually entered into the black hole, and the BH died shortly after that.


# December 16, 2004 5:15 PM

Bertrand Le Roy said:

I disagree with this interpretation. From our reference frame, the very moment when the object crosses the horizon is infinitely distant in the future, even though from its own reference frame, what seems infinite to us is actually finite for it. It's not just photons being detected with lower energies.
If you compare the two events (the moment the black hole evaporates and the moment the particle should enter the horizon - if it still exists -), their succession is clear: one happens in finite time, not the other. Thus, it is clear that the object enters the horizon after the latter has disappeared if at all.
Any physically relevant coordinate transformation will maintain the order of these two events as they happen at the same place. So the horizon must recess before the particle enters it.
Your hypothesis that something "happened" to the object which results in it being inobservable after the black hole has collapsed does not seem to be backed by any necessity or evidence (I know, we're speculating here anyway). But I think my hypothesis is backed by the fact that it does not rely on any new or mysterious phenomenon - no deus ex machina - and is consistent as far as I can see. There is no problem with the object not seeing the horizon recess (no object can see the horizon itself anyway).
I think you're right in saying that the actual disappearance of the black hole is pure speculation as we don't know the pysics of this scale, but we don't need to wait for that moment. Even when the final moment of evaporation is still far in the future, I think we can see that the horizon recesses faster than the particle approaches it from the arguments above.
Except of course if I'm overlooking some phenomenon or if my understanding of the evaporation of black holes is too naïve to be of any use.
But I'm really curious to see the advice of specialists of the field.
# December 18, 2004 6:06 PM

Bertrand Le Roy said:

OK, so the gurus agree that IComparable should really only be applied to immutable objects. So if you implement it on mutable objects, you must be breaking something. What you're breaking depends on what requirement you sacrificed in your implementation of Equals and GetHashCode. The documentation may be updated in the future to reflect that.
One other thing you could do is provide a method that enables the locking of the objects before you use them as keys in a collection object where the hash and Equals must be in sync (for example Hashtable), but that is a half measure as the users of your class must know about this problem and agree to lock the objects before using them as keys. Throwing from GetHashCode if the object is not locked could help prevent the problem.
Now, doing that is not ideal as it kind of breaks the pattern whatever you do: GetHashCode is implemented in object and it's not supposed to throw.
So the advice is "don't" and expect unexpected consequences if you do.
# December 18, 2004 6:19 PM

Sigurdur G. Gunnarsson said:

Thank you, that clarifies things quite a bit. And yes it would help if the documentation stated that "IComparable should really only be applied to immutable objects".
# December 21, 2004 6:13 AM

TrackBack said:

# December 22, 2004 10:43 PM

SuperJason said:

I really hope ASP.NET 2.0 makes this easy AND reliable AND cross-browser compliant. That would really allow some online applications to shine.

Traditionally, I have tried to avoid this as much as possible.
# January 4, 2005 8:31 PM

Bertrand Le Roy said:

Absolutely: it's easy, reliable and cross-browser.
# January 4, 2005 8:35 PM

rick said:

It will be cross-browser? Surprising, but that just made my day.

For other non-ASP.Net environments that want this functionality, there is the excellent JSRS (Javascript Remote Scripting) library (http://www.ashleyit.com/rs/). I was using this several years ago with PHP. I'm very excited that this stuff is finally catching on.
# January 4, 2005 9:14 PM

Adi Oltean said:

>>> If you compare the two events (the moment the black hole evaporates and the moment the particle should enter the horizon - if it still exists -), their succession is clear: one happens in finite time, not the other. Thus, it is clear that the object enters the horizon after the latter has disappeared if at all.

Well, my assumption was that the dissapearance of a black hole is an observable event (as predicted by theory when the mass of a black hole is extremely small), In this case, we can safely assume that some objects entered into it shortly before that event...

... If there is such thing as a black hole with a finite lifetime from our reference frame.
# January 5, 2005 5:28 AM

Bertrand Le Roy said:

Sure it's observable. Actually, that's kind of my point. How does that make it safe to assume that some object entered it (other than virtual particles created from the vacuum in the immediate vicinity of the black hole, whose information content is doubtful at best)?
# January 5, 2005 1:43 PM

Bertrand Le Roy said:

Not so surprising :) . Actually, most of the new features in ASP.NET 2.0 are cross-browser (Menu, TreeView with callbacks, the callback API, validators -finally-, GridView, etc.).
Interesting that you mention JSRS. There have actually been a few such APIs, including one by Microsoft, back in the classic ASP days, which was called remote scripting and surprisingly enough used a Java applet to communicate with the server.
The good thing is that the technology seems to be mature now with all browsers supporting it, and we can expect it to become mainstream this year.
# January 5, 2005 1:51 PM

bwaldron said:

So it looks like the compiler made an optimization because it knew that you were always concating the same number of values in your statement. I guess the rule of thumb for using StringBuilder is use it when what you appending varies based on something at runtime.

Good post...
# January 7, 2005 6:04 PM

Aapo Laakkonen said:

The compiler should take care of switching to StringBuilder whenever neccessary. Users' should just concatenate with '+'. That's what Java compilers have almost always done. And it seems like .NET compilers do the same, sort of.
# January 7, 2005 6:57 PM

Bertrand Le Roy said:

bwaldron: yes, absolutely.
Aapo: yes, I know Java does this kind of optimization. The C# compiler, as can be seen here, does similar optimizations when it is 100% sure it's relevant. Note that it doesn't use StringBuilder, but something even more efficient, though.
I'm no specialist of the Java runtime, but I don't think it can reliably know in which case a StringBuilder should be used. It can guess (just as the .NET compilers does in this case), but I mean, in some cases, it would have to be really smart about the structure of the whole application to do this kind of optimization reliably.
What if you instantiate a string in a package and pass it as an argument to another method in some other package where it will be concatenated with something else repeatedly? How does the compiler know what to compile to, String or StringBuilder, in each case? Or does it do some kind of conversion on the fly?
Then again, I'm not a compiler expert, and this blog entry should be seen as that of an ordinary user of .NET who tries to see how to improve performance of his applications. I'm not judging the Java or .NET choices.
I'd be interested to read about what really happens in Java, but I suppose that the rule here is more or less the same: if you're concatenating a fixed number of strings, just use +, and the compiler will take care of the optimizations (Java or .NET). But in .NET, if you concatenate a non-predetermined number of strings, consider using a StringBuilder.
# January 7, 2005 8:01 PM

Bertrand Le Roy said:

Update to what I just said. It seems like the Java runtime or compiler does not always know when to use a stringbuilder instead of concatenation, so in Java, it's exactly the same as in .NET: you should know when to use which.
StringBuilder was actually only introduced in Java 5 (previously, you could use StringBuffer, which does not perform as well because it was thread-safe).
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StringBuilder.html
http://www.javapractices.com/Topic4.cjp
# January 7, 2005 8:08 PM

Fabrice said:

One thing to know when using a StringBuilder is that it's good only when using Append(). If you try to use the Insert() method, you'll get really bad performances, because existing characters get shifted to make room for the new text.
# January 10, 2005 8:05 AM

TrackBack said:

Here are two more great blog entries about preventing SQL Injection Attacks....
# January 20, 2005 10:02 PM

Eddie Garmon said:

Instead of hard coding just add this to your class...

private static int _UnitMaxValue = (int)typeof(Unit).GetField("MaxValue", BindingFlags.NonPublic | BindingFlags.Static).GetValue(new Unit(0));

Its only evaluated once, and of if needed.

Eddie
# January 25, 2005 9:29 PM

Bertrand Le Roy said:

Eddie, that is an excellent point. Thanks!
# January 25, 2005 10:11 PM

Sean Gahan said:

Great Link!
My NerdyNess was a mere 89; I'm only a "High-Nerd."

Best Wishes,

Sean
# January 26, 2005 4:20 AM

Will said:

WTF? Did I just stumble into a LiveJournal blog? Are you a 14-year-old girl? "What X are you?" tests are a blight on the intarweb, only slightly less irritating than foot fetish sites and Fark's comments sections. Please, never EVER take another test again, and if you do, keep it to yourself. Thank you.
# January 26, 2005 8:45 AM

Bertrand Le Roy said:

Will, this is my blog, and if you don't like what you read here, you're very welcome not to read it.
By the way, how do you know that foot fetish sites are irritating?
# January 26, 2005 1:22 PM

Robin Debreuil said:

Will clearly has a foot fetish, but I suspect he failed the online test to get into the metatarsals video section. Don't sweat it Will, the calcaneus is way more erotic once you learn to appreciate the twin arches. Two words for you: 'toe socks'.

That being said, I'm just a 90, I knew I shouldn't have let the kids take that microscope apart. I don't know about that Friday night question though - 'bed at ten' was as close as I could get, though in reality I'm just under the blankets playing with my feet. Surely that is worth 3 extra marks?

# February 2, 2005 7:04 AM

EtIeNnE said:

Please note a small mistake here: in VB you CAN use += as a concatenation operator!
# February 22, 2005 3:26 PM

Doug Seven said:


This is a great post. Russ Nemhauser and I just covered this exact topic as one of our "small-but-useful" tips in a recent conference workshop on Performance and Scalability. Its little things like this that when multiplied by hundreds and thousands of users really add up to tangible performance gains.

I should add that when you are concatenating strings with variable values, you should use a StringBuilder to "accumulate" the string. Concatenating variable values with "+" or "& _" can add up to a perf hit because at the IL level this is still multiple values that are concatenated at run-time.
# February 22, 2005 4:58 PM

Bertrand Le Roy said:

Etienne: sure, you can. Most VB6 developers are used to the & syntax, though.

Doug: see this other post: http://blogs.msdn.com/bleroy/archive/2005/01/07/348831.aspx on concatenating with variable values. It's not the fact that you concatenate with variable values that really matter in the choice of a StringBuilder, it's really if the number of things you concatenate is variable: the compiler uses String.Concat(object[] a) when you concatenate a fixed number of objects, and that's significantly faster than StringBuilder.
# February 22, 2005 5:06 PM

Sushant Bhatia said:

I have a question on strings and how they are represented in IL. A while back I ran into this.

PROBLEM STATEMENT - Going through my project for work with the ILDASM tool was quite interesting. I noticed the following line:-

IL_000b: ldstr "There was a problem while trying to cancel authent" + "ication. Please inform the trainer."

Why is the IL split? My first though was that the string is being concatenated at runtime by the JIT. Then I looked up the ldstr on MSDN and found this quote:

The ldstr instruction pushes an object reference (type O) to a new string object representing the specific string literal stored in the metadata. The ldstr instruction allocates the requisite amount of memory and performs any format conversion required to convert the string literal from the form used in the file to the string format required at runtime.


So I scratch my head again and wonder why the sting was broken into two parts. First part exactly 50 characters long?

POSSIBLE IMPLICATIONS - Anytime you have a string that is more that 50 characters long, it will automatically be split when written in IL. Then during JIT, it will be concatenated. I also read somewhere that if you have 4 or more string concatenated, then you really should use the StringBuilder. Does this mean that any string 200 characters or above should be created using the StringBuilder?

What effect does this have on Resource Strings from your Resx files?
# February 22, 2005 6:10 PM

Bertrand Le Roy said:

First, the plus sign that you see in ILDASM is *NOT* anything real. I think it's just here to make it more readable. In reality, there's only one string. You can check by opening the exe file in a hex editor instead of with ILDASM.

Second, saying that concatenating more than four strings should be done with a StringBuilder is an oversimplification, and it's simply not true when concatenating a fixed number of strings (see http://blogs.msdn.com/bleroy/archive/2005/01/07/348831.aspx ). Four is a little low, too, even if the number of strings is variable.
# February 22, 2005 6:23 PM

TrackBack said:

# February 22, 2005 8:06 PM

TrackBack said:

# February 22, 2005 9:23 PM

freedumb fighter said:

Manks thanks for explaining #1 -- I had been doing all my checks as != null and was mystified why they were failing.
# February 24, 2005 12:36 PM

Brian Beatty said:

What about using string builder
sb.append("line1")
sb.append("Line2")

or string. format?
# February 24, 2005 12:58 PM

Bertrand Le Roy said:

Brian: see this other post on why stringbuilder is not always a good choice: http://blogs.msdn.com/bleroy/archive/2005/01/07/348831.aspx

In particular, when concatenating a fixed number of static strings, it's just a waste of time and it will perform significatly worse than just putting the concatenations in a multiline instruction: the compiler optimizes this away perfectly. There is no way anything can be faster, and it's readable.

String.Format is the worst approach. It performs very poorly when compared to both concatenation and stringbuilder.
String.Format has the advantage that it's very readable, but if you care about performance, you should only use it when the format string is not known in advance (for example if it can be set by user code).
If you know the format string in advance, it will be functionally equivalent to a fixed number of concatenations of variable objects.
So this means that string concatenation is what performs the best in this case too, not StringBuilder, not String.Format.

By the way, if you're thinking about inserting variable elements in a Sql query using String.Format or any form of concatenation, think again. The security risk is just too high.
Read http://weblogs.asp.net/bleroy/archive/2004/08/18/216861.aspx for more details on this.
# February 24, 2005 3:10 PM

Laurent Kempé said:

Sounds really cool !!! I planned to have a XSLT rendering of the article of Tech Head Brothers website as Word 2003 documents, using WordML, but it is not on a high priority on my task list, at least far from the WSE integration to publish directly from Word 2003. But I will for sure have a look to this.

Thanks.
Laurent
# March 1, 2005 2:58 PM

Jeff Parker said:

Handlers are a great thing, I do wish they were more documented. But you can offload a lot of time comsuming processing to Handlers. I wish I could find the article on MSDN somewhere that shows how to use a threaded timer in a HttpHandler to do the heavy lifting of a website things like email and so on, It was written by one of the guys working on ASP.NET a knowledgable guy by the name of Ron Howard.
He touches on this technique in this article below but he has a complete write up on it somewhere.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp11022004.asp

But you can use handlers for security as well this is one of the things like I said that has great potential unfortunately so very lightly documented http://www.dotnetspider.com/technology/kbpages/1011.aspx
# March 3, 2005 9:18 AM

Bertrand Le Roy said:

I think the guy you're looking for is Rob Howard. Ron Howard is the bald guy who makes movies and used to play Richie Cunningham in Happy Days.
You can get in touch with Rob on his blog:
http://weblogs.asp.net/rhoward/
# March 3, 2005 1:56 PM

Jeff Parker said:

Hah, yes you are correct Rob Howard. My Bad, well we both knew who I meant anyway.
# March 3, 2005 2:16 PM

Uwe Keim said:

Regarding point 2.): can you or any reader recommend some libraries?
# March 4, 2005 1:48 AM

Bertrand Le Roy said:

And this one that I just found on TSS.NET:
http://www.windwardreports.com/
# March 4, 2005 3:44 PM

MoonLite said:

#1 needs a little supplement though...

example:
the variable "val" does not yet exist.
if you do :

if ( val ) doSomething;
else doElseThing;

JavaScript will crash, because "val" does not exist, and does return neither "null" nor "undefined" nor "false".

The workaround I use is :

try { if ( val ) doSomething; } catch(e) { doElseThing; }

If used often, consider using a function:

function exist (a) {
try { var b=a;}
catch(e){return false;}
return true;
} // exist

so you can just use:

if ( exist (val) ) doSomething;
else doElseThing;


it's advisable to put all your code in :

try { ... your code ... } catch (e) { alert (e); }

browsers like FireFox will give a little detail on the problem when encountered.
# March 5, 2005 11:55 AM

Bertrand Le Roy said:

Moonlite: while you are right that an undeclared variable will trigger a javascript error, I would certainly not encourage anyone to go ahead and include the test in a try/catch.
The right workaround here is to declare all your variables, even if you don't initialize them immediately. In this case, they will undefined, but the test will not crash.
There are very few cases where you need a try/catch. They do exist, but this is not one of them.
Thanks for the heads up, though.
# March 7, 2005 1:32 PM

Salman said:

Yup its Rob Howard. Jeff P., download the latest version of CS and you will see that code snipped.
# March 9, 2005 7:40 AM

TrackBack said:

Bertrand LeRoy illustrates how easy (well, relatively) it is in Whidbey/Visual Studio 2005 to create HttpHandlers (.ashx files). Ease of development aside, he points out that handlers are a comparatively less-understood feature in ASP.NET. He says: "T ...
# March 14, 2005 6:44 PM

TrackBack said:

# March 22, 2005 8:33 AM

TrackBack said:

# March 22, 2005 9:31 AM

TrackBack said:

# March 22, 2005 11:00 PM

TrackBack said:

# March 22, 2005 11:01 PM

Jerry Pisk said:

So in Whidbey one has to template the method signatures in addition to the type definition? instead of C++:

class <T> MyClass {
T GetService();
}

we have to do:

class <T> MyClass {
T GetService<T>();
}

isn't that a little too much?
# March 28, 2005 3:16 AM

Bertrand Le Roy said:

No Jerry, you never write that second thing, which would probably not compile because that would create a conflict between the class type parameter and the method type parameter. You write something close to the first one:

class MyClass<T> {
T GetService();
}

I should maybe have written the code for the entire class. What you have in my example is a generic method in a non-generic class:

class MyClass {
T GetService<T>();
}
# March 28, 2005 2:02 PM

Rolando said:

so you're a Microsoftie... and by your blog title and the content of your posts you don't seem to be part of the ASP.NET team

Why is your blog still here at weblogs.asp.net ?

Did Somebody forget to move you to blogs.msdn.com ?
# April 1, 2005 8:44 PM

Bertrand Le Roy said:

I am part of the ASP.NET team. What makes you think I'm not?
# April 1, 2005 8:46 PM

Rolando said:

sorry Bertrand... the content of your latest posts confused me...

by the way... is there any chance that ASP.NET team bloggers could be identified ? maybe a link like "Posts by only ASP.NET team Bloggers" replacing the "Posts by only Microsoft Bloggers" that now returns nothing ?

# April 1, 2005 8:50 PM

Bertrand Le Roy said:

I don't know. You'd have to ask Scott. I agree that it would be useful.
# April 1, 2005 8:51 PM

Steven Smith said:

Good stuff. For more info on the various ways to manage state in ASP.NET, readers might check out my MSDN article:
http://msdn.microsoft.com/msdnmag/issues/03/04/ASPNETUserState/
# April 2, 2005 10:41 AM

sugandh said:

hi, i want to know what r the implications of Viewstate on XMLHTTP.
I am getting an error in that and i feel it is because of viewstate.
# April 2, 2005 11:54 AM

Bertrand Le Roy said:

Steven, thanks for the pointer. I knew your article but couldn't find it, so thanks.

sugand: there should be no implication of viewstate on XmlHttp. If you tell me a little more about your specific situation, maybe I would be able to help. Are you using the ASP.NET callback feature or XmlHttp directly?
You can drop me a note at bleroy at Microsoft.com.
# April 2, 2005 10:08 PM

TrackBack said:

# April 3, 2005 1:40 PM

TrackBack said:

# April 4, 2005 12:25 AM

Oleg Ufaev said:

# April 4, 2005 4:08 AM

Bertrand Le Roy said:

Oleg: what's wrong with the url? I just tried it, and it works. What happens when you click on it?
# April 4, 2005 2:19 PM

Ron A. Buckton said:

I was working on a project for DDI (www.ddiworld.com) back in 2002 when .NET 1.0 was released. The project used OOB/XmlHttp stuff from the getgo, and MS even did a case study way back when (http://www.chroniclesdesign.com/ddi.pdf).

Prior to that I was using XML-RPC way back before SOAP in my ASP days, yet more XmlHttp. Its definately nothing new, but until recently there's never really been much of a "framework" for OOB support. (Excepting webservice.htc, which was still only a small piece of the puzzle).

New features like client-callbacks should make this easier in .NET 2.0 (and even 1.x, I have some sample code in a SIG presentation I did (http://www.bennettadelson.com/downloads/NetSigSolution2-8-05.zip) and will have an article on it in a couple days on my blog), building in a lot of support directly into .NET.
# April 8, 2005 11:39 PM

JosephCooney said:

I think the WebService DHTML behavior (on the client) and ASMX on the server is much better than ASP.NET's async callbacks....so much so that I wrote this sample comparing the two.

http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=fd6acac1-da45-446c-822d-5b2ecdb396a6

and this critique of it

http://jcooney.net/archive/2004/02/26/343.aspx
# April 9, 2005 4:25 AM

TrackBack said:

# April 9, 2005 4:39 PM

TrackBack said:

^_^,Pretty Good!
# April 10, 2005 5:39 AM

TrackBack said:

^_^,Pretty Good!
# April 10, 2005 5:40 AM

TrackBack said:

Best of the Blogs - Ian Smith reviews the best of the last week's web development blogs so that you don't have to. Week ending 10th April 2005. Whidby, Visual Studio Team System, Visual Studio 2003, Training, Productivity Enhancers, Front-End Development and more...
# April 10, 2005 5:14 PM

TrackBack said:

Bertrand Le Roy, one of the rock-star developers on the Web Platform and Tools team has been doing a...
# April 10, 2005 7:51 PM

Uwe Keim said:

Great! I already played with this, too. Seems that this ASP.NET 2.0 Callback stuff also seems to be aware of different browsers and works correctly on FireFox, too?!?
# April 11, 2005 12:30 AM

Bertrand Le Roy said:

Uwe, it depends which build you're using. The beta builds should play nicely with Firefox, and the final version will address more browsers, like Opera.
In any case, any control you develop with this technology should degrade gracefully to ordinary postbacks on older browsers. It's the case of some of my samples, but not all, for the sake of simplicity (they are sample, not production quality controls).
# April 11, 2005 12:43 AM

Bertrand Le Roy said:

Joseph: The callback feature IS aimed at control developers. You seem to forget a small detail about behaviors: they're only available on IE. The ASP.NET callback feature already works on IE and Firefox and the final version will work on more browsers.
The example about wiring up several text boxes can be solved by the CallbackMultiplexer sample control that's included in my sample workspace (http://www.gotdotnet.com/workspaces/workspace.aspx?id=cb2543cb-12ec-4ea1-883f-757ff2de19e8).
Another problem with the web service behavior when compared with the ASP.NET callbacks is that you need to create a web service for each control, whereas with callbacks, everything is integrated in the page and control lifecycle.
That's very important: with web services, there's no way you're going to be able to access other controls on the page and integrate them in your update procedure. With callbacks, your update procedure executes in the context of the page, so all controls are fully available.
# April 11, 2005 1:13 AM

Steven Livingstone said:

Belive it or not the last few days i have been working on moving some old Remote Scripting features of a huge system to use XMLHTTP.

The feature above sounds very interesting. I assume it works fine through firewalls and proxies!? (i ask as this is on reason we are moving from Remote Scripting which runs into trouble over our proxy when using an older Sun JVm on the client!).

They key is if you guys can get this to just work cross-browser. I like the idea and would be very intersted in how this ties in with ViewState and postbacks.
# April 12, 2005 3:55 AM

JosephCooney said:

I was less-than-impressed with the async callback feature since it did NOT work in firefox IIRR in the PDC release that I tested, but it is great news if it will work on more in the final release. For control developers I can honestly see the benefit, but if you went the web-service route instead of the ASP.NET async callback route you don't necessarily need 1 web service per control, you just need one webmethod per type of async operation you want to perform.

I don't really buy into the "can't access other controls on the page" argument. If your using web services and need the state of the controls to be sent back to the web service you can just do that from your callback code. Using ASP.NET async callback you can't change the properties of the control inside the callback anyway, becuase the viewstate has already been written to the client (unless some very impressive script has been added in the last little while to re-write the viewstate on the client once the call returns).

I love the async idea (especially the part about making it easy) - I just wish it could have been more strongly typed. The client-side script that the current DHTML behavior could have been rolled into a control, so the fact that it is currently in a DHTML behavior is more of an implementation issue IMO.
[cross-posted from my weblog, with some more junk as I thought it up]
# April 12, 2005 4:58 AM

Bertrand Le Roy said:

Steven: it works with proxies and firewalls. Callback requests look just like any other http request from the exact same client as far as the firewall is concerned. And it does work cross-browser (IE and Firefox are supported for the moment, more to come for RTM).

Joseph:
It didn't work with Firefox in the PDC build, but let's be honest, what did? The PDC build was an early alpha. Beta 2 should be available any time now.
If you're using callbacks, you can have the same reusability you have with web services by isolating the code in a separate method and just calling that from your event handlers. Actually, it is pretty obvious that this is the good practice if your callback logic is not specific to this control.
The only state you can use with the web service approach is the client-side state, not the server-side state. That means more client code, and nobody want that, right? With callbacks, you just have access to your other controls as usual, it just works. With web services, your client-side code has to take the client-side state (if it exists at all in a usable form: think about the state of a TreeView) and package it into XML for the web service to consume.
The real reason why the ViewState is not updated during callbacks is that the page lifecycle is not completely executed, and because several asynchronous callbacks can happen at the same time in the current build (which is not beta 2). Otherwise, it would be fairly easy to send the new value of the viewstate back to the client.
Anyway, I'm not talking about *changing* the state of other controls on the page, I'm talking about using it.
The point is that ASP.NET callbacks are fully integrated into the page lifecycle and web services are not. This has many advantages, another one being ease of writing.
I understand your point about strongly typing. The problem is that there is a huge impedance mismatch between the JavaScript type system and the SOAP and .NET type systems. If you go the strongly-typed way client-side, where do you stop?
I kind of like the frameworks that try to give you client-side an object hierarchy that looks like what you have server-side, but that a *very* leaky abstraction. It looks nice, but it is actually an illusion IMHO. It increases the complexity of the client-script, and it's only nicer if you actually intend to write a lot of client-side code and need a clean object model there. The truth is, most people don't want to touch client-side code, they want to write as little as possible. So far, strings have been just fine for all our scenarios. We do some simple parsing in the TreeView case, but TreeView is already a very complex control.
Another thing to consider is that the callback API is just that: a relatively low-level API that enables you to forget about the complexities of communicating cross-browser with the server. The idea is that people will build stuff on top of it. For example, I don't know if you checked out my samples, but there is a very interesting thingy in there that's called CallbackMultiplexer and it does something like a more strongly-typed callback in a very transparent way. You could very well build a control on top of our callback API that does marshalling in a more strongly-typed way, à la Web Service. After all, XML is just a way to marshal strongly-typed data using a string.
You know what, I think I agree with you that there are scenarios where you will want something more strongly-typed that a string, and I think I'll build a control that does that for you. I'll add it to the sample collection when it's ready. :)
Thanks for the comments.
# April 12, 2005 2:28 PM

Fregas said:

I think all of this: AJAX, Callbacks, XmlHttp, etc. just illustrate how crappy the HTML/HTTP model actually is right now. In windows and java applications, this kind of stuff is relatively simple. In the web world, we always seem to be trying to catch up to where the desktop world has been for ages. Hell, forget about catching up, we're just trying to get close!

Simple things like Drag & Drop or populating a drop down list without a refresh are a huge pain in the ass in DHTML/Javascript. They shouldn't be. The need not be. All this stuff in ASP.NET 2 and its like (while definitely nice to have) are just band-aids over the real problem. I think the bottom line is that we need to scrap HTML as the client/presentation layer and replace it with something else. Call me a dreamer... :)

Long live SmartClients! Long live XAML! Long live FLEX!
# April 12, 2005 3:28 PM

Bertrand Le Roy said:

Fregas: I agree completely that in an ideal world, we would all be doing declarative rich client applications. But the web is here to stay for at least a few more years, and it's still the best answer for a lot of application types. Not for technical reasons (even though the web is still superior for a number of things, like being very flexible with document layout), but for pragmatic reasons.
It is our job at ASP.NET to make Web application development less painful (if not fun altogether). Callbacks are one more step in this direction.
But if your application can be done using rich client technologies and not loose a large number of its customers along the way (think Amazon in WebForms... doh!), go ahead and do it, sure.
# April 12, 2005 3:35 PM

TrackBack said:

Brian Goldfarb sent me an email pointer to the latest ASP.NET Support Voice posting.&nbsp; This one covers...
# April 12, 2005 5:33 PM

Fregas said:

Well, thats the rub isn't it? -IF- the W3C or some other organization would come up with a standards based presentation layer that made sense and allowed all this rich interactivity, -AND IF- all the browser vendors would support this standard without devolving into more browser wars...well then, we'd all be better off: Users, Developers and Companies who want a good ROI.

Not likely to happen, unfortunately. There are whispers of it in things like Flex and Xaml, but no standard in sight yet.

ASP.NET definitely makes things easier in most ways (although not all.) But i'm tired of hearing about things like AJAX which is sugar frosting on top of layers and layers of crap. AJAX doesn't make my job easier. Instead, it gives people who don't know any better the impression that there is now a new technology to make the web "desktop-like" and make all their UI dreams come true. Come on. We don't all have the resources and know-how of google.
# April 13, 2005 10:10 AM

Bertrand Le Roy said:

Fregas, I understand what you're saying and I almost agree. I know that some customers/bosses can be a pain when they've read about a cool new buzzword like AJAX. So as a word, I agree that AJAX may be harmful to the industry in the sense that it diverts attention from the fact that the technology it describes is in no way a universal answer to the fundamental suckiness of the web.
On the other hand, I hope that our work (which predates the buzzword) will make it a little easier for people like you (our customers) answer your boss's or customer's demands. I'm not trying to amplify the buzz in any way, just to make it easier for our customers.
I agree, we're not all Google. Actually, Google Maps is a very impressive piece of software in many ways and reducing it to just an AJAX application is an insult to the talent of the Google engineers.
# April 13, 2005 2:06 PM

Robert McLaws said:

Can you post the source for these controls?
# April 15, 2005 5:19 PM

Bertrand Le Roy said:

The link to the source code was in the first post, but I added it to the new post so that it's easier to find... http://www.gotdotnet.com/workspaces/workspace.aspx?id=cb2543cb-12ec-4ea1-883f-757ff2de19e8
# April 15, 2005 5:22 PM

TrackBack said:

# April 15, 2005 5:54 PM

TrackBack said:

# April 15, 2005 8:21 PM

TrackBack said:

Interesting finds this week
# April 17, 2005 12:38 PM

TrackBack said:

Ian's weekly review of the best of the blogs for the .Net developer week ending 17th April 2005
# April 17, 2005 3:55 PM

Cleve Littlefield said:

I disagree about the lack of need for strong typing. While full objects may be an allusion, something simple like supporting muliple parameters, not just a string input and a string output, is very useful. Here is a good example...

http://weblogs.asp.net/mschwarz/

Although this is a leaky abstraction, most of ASP.NET is a leaky abstraction of some sort or another...
# April 22, 2005 3:36 AM

Bertrand Le Roy said:

Cleve, with what exactly do you disagree? I never said there is no need for strong typing. One of my samples does precisely that: supporting multiple parameters...
About leaky abstrations, read my post about them: http://weblogs.asp.net/bleroy/archive/2004/12/02/274105.aspx
# April 23, 2005 10:37 PM

TrackBack said:

# April 24, 2005 1:37 AM

TrackBack said:

Steve Friedl has a great explanation of how he used a SQL injection attack to compromise a Web site. (Which is what he was asked to do.) It features a blow-by-blow account of what he tried, what results he got, and how he used his failed attempts to le ...
# April 27, 2005 1:09 AM

Sheetal Jain said:

Couldn't agree more - In our of our product we had written a strip out version of NanoXML parser as a applet to make server call to updaste <div> tags and this was back in 2000

# April 27, 2005 10:58 AM

TrackBack said:

# May 6, 2005 5:21 PM

TrackBack said:

wagnerblog.com &raquo; Fun with callbacks Part 1: What&#8217;s in the ASP.NET box?
# May 8, 2005 2:00 PM

TrackBack said:

# May 19, 2005 6:55 AM

TrackBack said:

# May 19, 2005 6:56 AM

TrackBack said:

Callbacks in 2.0
# May 19, 2005 2:27 PM

Peter Bromberg said:

Very classy stuff, Bertrand! Especially the RefreshPanel at gotdotnet.
# May 21, 2005 12:19 PM

TrackBack said:

# May 25, 2005 11:58 AM

TrackBack said:

# May 25, 2005 11:58 AM

Sergey Polyakov said:

Callbacks look like great techology capable to improve web controls development significantly.
Thank you Bertrand for introducing the technology and providing us with amazing demos.
My question is: are request params (the form input values) available during callbacks?
# May 31, 2005 6:37 AM

Bertrand Le Roy said:

Sergey: during a callback, the page is in exactly the same state it was during the last postback, so the Form and QueryString parameters are still available, in addition to the callback parameters. Does that answer your question?
# May 31, 2005 9:03 AM

Steve said:

This is good, but what about the current 1.1 version - this stuff you are doing is all beta material that can't be used on production environments.

See http://www.dart.com/powerweb/livecontrols.asp

I just wish these controls were cheaper :)
# May 31, 2005 9:25 PM

TrackBack said:

# May 31, 2005 11:29 PM

Sergey Polyakov said:

Bertrand, I meant whether are available the actual input values (at the moment of a callback) which have been changed since the last postback, but from your post I see that they are not available and only old values from the last postback can be obtained (and this is exactly what I observed in my test project). In other words I need to pass manually through the callback args all the information I want to gather from the page. Am I correct?
# June 1, 2005 2:59 AM

Bertrand Le Roy said:

Yes, you are correct. It looks a little counter-intuitive at first, but it ensures that the page is in a consistent state during a callback even if multiple callbacks are triggered at once.
The data that you want to be up-to-date must be passed as a part of the callback parameter, and Form will have the values it had during the latest postback.
# June 2, 2005 1:17 PM

TrackBack said:

This entry is an introduction to ScriptCallbacks in ASP.NET 2.0 and a few observations and comments on the design and implementation. It seems this interface provides a core engine behavior that is pretty low level, but doesn't do anything to facility the actual process of data exchange between the client and server.
# June 6, 2005 6:03 PM

Hank Fay said:

I resemble that remark, and here's my internal dialogue at such a moment:

If it's my marker: "I'd better keep it, so I remember what kind of marker and what color to buy."

If it's someone else's marker: "I'd better not throw it away: they might need to know what kind of marker and what color to buy."

It would be interesting to collect internal dialogues for this common behavior.
# June 14, 2005 11:40 PM

Peter Bromberg said:

So long as my callbacks don't die, I can live with the marker problem.
# June 15, 2005 10:20 AM

smelliot said:

this is why I always go for the brown markers- everyone hates brown, so it never gets used.

Also- I toss them- the prob (as stated by Hank), is that "if it's not mine, I can't throw it away"

In addition, they're always crap because "If it's not my whiteboard, I can't order supplies for it" or possibly rather, "If it's not mine, it'll still go onto my budget".

I haven't been to an org that has budgets for inanimate objects, but probably should.
# June 15, 2005 5:25 PM

Srikanth said:

I know this is n't the right message post for my question, but since you are an callback guru, i would like to post my question here.
How do we handle callbacks in the frame scenario.
For ex: Suppose i have three frames (pages) with Topnav,Sidenav and Remainingspace aspx page.I'm doing a callback from menu on the topnav that changes the data on the topnav page(html) and since we call response.end after the callback event,i could n't get to the leftnav to get loading with the new topnav changes.In otherwords the response stops with the topnav page and i'm not able to keep the pages rendering on the leftnav and mainspace page.Any ideas? appreciate your help.
# June 18, 2005 11:10 AM

Bertrand Le Roy said:

Well, if you do frames, it's the same as with postbacks, you'll have to use some client script to modify other frames (the server-side has no idea of frames).
# June 27, 2005 2:40 PM

Srikanth said:

Thank you. Someway or rather i figured out the answer after posting it in your blog.I guess reading your articles gave me the answer already.Anyway thanks for the excellent articles on callback stuff.
Keep up the great work!
# June 27, 2005 10:22 PM

AndrewSeven said:

I'm glad to see both.

I only looked at the Schwartz Interactive AJAX, but it is so simple to use.
You don't need to know about xmlHttp to use it and on the server you could just use an ordinary aspx page with the functions. In pages where you want to use those functions you call a register for ajax method.
# July 14, 2005 6:00 PM

Karl said:

Any solution that requires developers to manually serialize their wonderful objects and then do something meaningful in JavaScript with it is gonna fall flat on it's face. Until such time as good tool support for JavaScript exists, and developers learn that JavaScript is actually OO, even poor developers are going to realize that their code is unmanageable and hackish.


Ajax.Net might provide a "leaky abstraction" (thank's joel for that one!), it's still pretty productive:

var ds = response.value;
for (var i = 0; i < ds.Tables[0].Rows.length; ++i)
{
var firstName = ds.Tables[0].Rows[i].FirstName;
var lastName = ds.Tables[0].Rows[i].LastName;
}

for the win!!

Karl

# July 15, 2005 9:55 AM

Scott Wisniewski said:

You should take a look at the "Power Web Controls" provided by Dart.
One thing they do really well is preserve the user's (the app developer) mental model of how ASP.NET works. The client callback support in Whidbey does not do that, however.

In fact, I think you are in a bit of a catch 22.
You want to enable the developer to drop a control on a page and have the control be self contained in order to preserve their mental model for developing web applications.

However, the limitations of the way callback support is implemented break the user's model: callback event handlers cannot change view state, and the current form values are not collected and posted to the page. This means that a callback running inside a page (the simplest, and hence most likely, scenario involving callbacks) doesn't have access to any of the values users have typed in.

I know some people have expressed concern that collecting the form values can cause validation issues, but that can be resolved by requiring the callback mechanism to fire off the validation process.

In order to keep the callback mechanism, as its implemented now, without breaking the user's mental model you need to split it apart from the page. The callbacks don't have full access to the page (or control) on which they reside, and a result shouldn't be there. If a user places two methods on a page, one that responds to a callback event and one that responds to a post back event, he or she will naturally expect both methods to have access to the same state. However, they don't. The post back handler has access to the values the user (of the web app) typed in, where as the callback does not. The reasons behind the discrepancy stem solely from implementation details and are not immediately obvious to the user (the programmer). It's a prime example of the system implementation leaking into the user's mental model. That's not a good thing.

By splitting callback event handlers out into separate http handlers, the user's mental model is not violated in this manner. The handler is separate from the page, so it makes sense that it doesn't have access to the page.

However, separation is not the answer. It still violates the user's mental model. In particular, it flies in the face of modularity, something ASP.NET is really good at enabling. This is where the catch 22 comes in.

I think the solution is simple: enhance the callback mechanism to grab current form values before postback and to automatically update viewstate and control appearance after the callback. I'm not saying that's simple. In fact, I think it will be pretty difficult, and that it really isn't feasible to see something like that in Whidbey. However, I really think you should look into it for orcas.

I'm also not saying that the callback support isn't useful. For custom control developers (expert level ASP.NET users), the callback mechanism provides a great foundation for developing really awesome controls. I think as a result of it you will start to see some really great things come out of the ISV's developing controls for ASP.NET. As expert users, however, custom control developers are willing to "go the extra mile" necessary to maintain the correct user experience.

For the vast majority of "page oriented" ASP.NET developers (intermediate users), however, I think that the callback support in will prove to be a large source of confusion.
# July 15, 2005 12:31 PM

Bertrand Le Roy said:

Karl, I agree 100%. You need to check out my RefreshPanel library (follow this link: http://weblogs.asp.net/bleroy/archive/2005/04/08/397761.aspx and read on), especially the serialization stuff and the RefreshProxy. As I've been explaining in previous posts, the callback infrastructure provides you the low-level plumbing to enable out-of-band calls in a server custom control. It is easy to add a higher-level layer on top of that, as I hope I've demonstrated with this library.
I also mostly agree with the object-orientation remark, and this is precisely what we're going to address with Atlas. What I disagree with is the point of JS being OO. It is not really, but you can sort of hack it into being OO. What it has is closures. In Atlas, we're /implementing/, or adding if you prefer the notions of class inheritance, interfaces, strong types, etc. Stay tuned, I think you'll like what we're doing when we unveil it at PDC.

Scott, two things. First, believe me, we would have *loved* to maintain ViewState during callbacks, but it's very difficult for one simple reason that I've explained in a previous post: only one postback for any given page happens at once, whereas callbacks would be pretty much useless if you couldn't have several happening at the same time. So you may know the order in which you send the callbacks, but there's no way you can determine the order in which they'll come back. So which version of the ViewState are you going to choose? To maintain the monolythic ViewState, you need sequentiality. One solution we've been thinking about for Orcas involves making the ViewState less monolythic and enabling the page to be broken into smaller mini-pages that would have their own isolated state and where local sequentiality of the callbacks would be less of a problem. The problem with such a model is that it becomes more difficult for these mini-pages to communicate with the rest of the page. In fact, the ideal granularity is the control itself, so the ideal solution would be for each control to manage its own state, and guess what, that's the current callback model, except that we don't provide many helpers for client-state management in Whidbey, and it can be difficult to reconcile your client-side state with the global ViewState on the next postback. Read the Fun with Callbacks series for more details.
Second, I think you make my point: there are two needs (and solutions), one for custom control developers (callbacks), and one for application or page developers (Ajax.NET and the future Atlas framework). One tool does not fit all...
# July 15, 2005 1:47 PM

Bertrand Le Roy said:

(oh, and yes, we know of the Dart controls and of several other similar libraries. They're great and I can only encourage people to use them if they answer their needs.)
# July 15, 2005 1:49 PM

Etienne Richard said:

Friday 5:30 pm idea...

> One solution we've been thinking about for Orcas involves making the ViewState
> less monolythic and enabling the page to be broken into smaller mini-pages that
> would have their own isolated state and where local sequentiality of the callbacks
> would be less of a problem. The problem with such a model is that it becomes
> more difficult for these mini-pages to communicate with the rest of the page.

How about implementing better AJAX support for WebParts based solutions using each webpart as granularity? In such a scenario, "breaking pages into smaller mini-pages" = "defining webparts". WebParts communicate with each other using a provider-consumer connection model. The webpartmanager knows all the dependencies that exist between webparts at runtime.

In this model, WebParts would serve as the autonomous logical parts of the UI. The page's postback and state mechanism would be delegated to each webpart. Each webpart would then be responsible for it's own state and for posting back to the server. Upon return of a postback, the webpart's display and state would be updated. Just like a normal page postback, but scoped to a webpart and using AJAX to refresh only part of the UI.

Now, what if a webpart's state is dependent on the state of another webpart. For example, a master webpart and a detail Webpart. When the selection in the master webpart changes, the detail must be updated accordingly. If each webpart acts independently for postback, the detail will never be updated. However, in the webparts framework, dependencies between webparts are declared through a provider-consumer connection model. Therefore, when a webpart posts back, it is possible to know dependent webparts by finding all consumers of any connection provided by the parent webpart. To answer the dependent webparts problem, upon a webpart postback, a simple rule could be to execute postback logic for each dependent webpart as well as for the parent webpart. Upon return, update state and display for all the webparts implicated in the postback.
# July 15, 2005 5:40 PM

Bertrand Le Roy said:

Etienne, WebParts and callbacks/ajax sure are interesting scenarios for the Orcas timeframe as well as for Atlas, but at this point we don't want to force WebParts as the infrastructure people would need to use to get these features. Portal features and better callbacks are orthogonal and we're more thinking about a user control or panel, which can be combined with WebParts but do not force one to use them.
It's interesting to consider, though, because of the way WebParts maintain and persist state, which is very different from what ordinary Controls do.
Thanks for the feedback.
# July 18, 2005 3:46 PM

teddy said:

good
# July 26, 2005 3:17 AM

Brock Allen said:

Hmm... Software isn't easy is it? :)

I doubt there's time left to do this, but I could imagine this being rolled into the Control base class to manage some of this complexity when not using the async model.

-Brock
# August 7, 2005 3:57 PM

Bertrand Le Roy said:

Too late for Whidbey, yes, but I'd be interested to read precisely what you have in mind (for, you know, Atlas or Orcas).
# August 7, 2005 7:33 PM

foobar said:

You can also clip the select box.
# August 9, 2005 7:25 PM

Bertrand Le Roy said:

foobar: yes, you can if you have only one DIV to overlay. In the case of a cascading menu, you would have to clip to something that's not rectangular, which is impossible. And it would be so much more complicated than this anyway...
# August 9, 2005 7:59 PM

Jon Galloway said:

Interesting. I was pretty sure that the Beta 1 hid all selects on the page when the menu was shown. It looked really funky; this hack is at least much better from a user point of view.
# August 9, 2005 8:07 PM

Bertrand Le Roy said:

Jon: you're right. Beta 1 used to hide all select elements. The iFrame hack is available in beta 2 and later builds.
# August 9, 2005 8:09 PM

Scott said:

We use "javascript:;" as the src to avoid the secure/non-secure warning. Works better than putting a blank page in the site IMO. :)
# August 9, 2005 9:13 PM

Bertrand Le Roy said:

Interesting. I'll update the post. Thanks for the tip.
# August 9, 2005 9:16 PM

Bertrand Le Roy said:

Ron, that's very nice of you, but there's already a link to this article in the post, if you look carefully. Thanks for making it more obvious, though.
# August 9, 2005 9:29 PM

Collin Yeadon said:

Thanks for the "hack". I will need to try that out. I have gotten into the habbit of solving this problem by avoiding it but if I can avoid making sacrifices then that's great.

I wonder if this would also work for other objects. I have a large flash movie that pops up on a site I am working on. The flash is set to be transparent and all the standard stuff to let it stay above the other page elements. But I noticed the DIV problem exists with my flash movie as well. I have a hunch that this same hack will make the div my flash movie is in also appear over the SELECTS.

Do you know if this hack is browser version specific? I wonder if IE7 has corrected this problem.
# August 9, 2005 9:59 PM

Bertrand Le Roy said:

Collin, in theory, it should also work for other objects such as Flash movies although the transparency of the Flash movie may be trickier than the simple DIV case. If you can try it, can you post here the results of your experimentations?
I don't know if IE7 plans to correct this problem. It's probably too early to tell but if they fix it the hack won't break because the non-windowed behavior is correct too (try the code in Firefox to verify it). I know that the way windowed elements used to work in earlier versions of IE was different and that this hack may not work on older IEs, though.
# August 9, 2005 10:07 PM

Collin Yeadon said:

Bertrand, am I missing something? The IFRAME has a white background.. so how is this solution supposed to work? Possibly something else in my app is breaking the hack?
# August 9, 2005 10:52 PM

Collin Yeadon said:

OK, well, I guess I know what you meant about transparent being a problem.

Results are in:

Testing in IE6, It does show up over the SELECT as suspected. So flash is no problem. But, I guess there is no way to make that IFRAME transparent so this hack works great only if your menu has a background to cover up the IFRAME.

Lets hope IE7 get this fixed.

Good to know about this method anyways. Thanks BLR!
# August 9, 2005 11:12 PM

Bertrand Le Roy said:

Collin, yes, I think you've got it figured out: the point of the hack is that the iFrame is not transparent... So for a transparent movie, I don't think this can help. But it definitely helps for a menu DIV.
# August 9, 2005 11:55 PM

Josh Twist said:

Hi Bertrand,

Just as a note - I don't think *anything* is cached when accessed through https (for obvious reasons).

Josh
# August 10, 2005 2:45 AM

Sébastien FERRAND said:

Thx for this hack...
# August 10, 2005 9:41 AM

dylan said:

Easiest way to do this is by dynamically creating and positioning the IFrame, so you don't have to think about it. Below is pseudo code.

if (document.all)
{
divNode.insertAdjacentHTML("afterEnd", '<IFRAME style="position: absolute;z-index:4;" src="javascript:false;" frameBorder="0" scrolling="no" id="' + sTableID + '_hvrShm" />');
var iframeShim = document.getElementById(sTableID + "_hvrShm");
iframeShim.style.top = hoverDiv.style.top;
iframeShim.style.left = iframeShim.style.left
iframeShim.style.width = hoverDiv.offsetWidth;
iframeShim.style.height = hoverDiv.offsetHeight;
}
# August 10, 2005 11:07 AM

Bertrand Le Roy said:

Josh: I updated the text.
Dylan: thanks for the code. A few potential problems I see with it, though:
* if you insert the frame just after the div node, I'm not sure selects that are declared after the div in the document markup will get covered. Plus, you may need to reposition the div itself as the frame may cover it.
* the frame coordinates may need to be corrected in the case of multiple offset parents if you have to put the frame at the end of the document instead of next to the div.
* personally not a big fan of document.all as an IE browser detection test. For all we know, that may disappear in IE7 in standard mode (not very likely, but it may happen). Furthermore, the capability you're using is insertAdjacentHTML (which is IE only too), so why not use that as the test instead of document.all?
Big thanks for the code, though.
# August 10, 2005 2:01 PM

TrackBack said:

Comment mettre un DIV au dessus d'un SELECT avec IE.
# August 10, 2005 8:28 PM

Steve W said:

For simple menus (with no submenus) you can also use the window.createPopup() method, and that goes over windowed elements.
# August 17, 2005 5:04 PM

Bertrand Le Roy said:

Steve, that's an IE-only solution, and as you say, it doesn't work for cascading menus. It's used in the IE-only script for the verbs menu in webparts, though.
createPopup has its own share of problems, like its document being a completely different environment that does not have easy access to its parent document.
I'd strongly advise against using it.
# August 17, 2005 5:23 PM

Collin Yeadon said:

Here is a solution to use when all else fails. I put this together from some code I found on the net. Basically it will hide all selects that show up under the div you are showing. You would pass the left, top, width and height values to this toggle script which hides them ONLY if the version is IE6 or previous. We can only hope that IE7 will have cured this because this is an ugly way to do it.

I am forced to use this as a solution with a flash popup that has a transparent background. If te background was solid then of course the IFRAME solution would look much nicer.

I was tempted to make this script write a div to the page, position it where the IFRAME is and then style it to look like a drop down list but decided that was just not worth the hastle.

<code>
function toggleSelect(x,y,w,h){
var appVer = navigator.appVersion.toLowerCase();
var iePos = appVer.indexOf('msie');
if (iePos !=-1) {
var is_minor = parseFloat(appVer.substring(iePos+5,appVer.indexOf(';',iePos)));
var is_major = parseInt(is_minor);
}
if (navigator.appName.substring(0,9) == "Microsoft")
{ // Check if IE version is 6 or older
if (is_major <= 6) {
var selx,sely,selw,selh,i
var sel=document.getElementsByTagName("SELECT")
for(i=0;i<sel.length;i++){
selx=0; sely=0; var selp;
if(sel[i].offsetParent){
selp=sel[i];
while(selp.offsetParent){
selp=selp.offsetParent;
selx+=selp.offsetLeft;
sely+=selp.offsetTop;
}
}
selx+=sel[i].offsetLeft;
sely+=sel[i].offsetTop;
selw=sel[i].offsetWidth;
selh=sel[i].offsetHeight;
if(selx+selw>x && selx<x+w && sely+selh>y && sely<y+h)
if(sel[i].style.visibility!="hidden") sel[i].style.visibility="hidden";
else sel[i].style.visibility="visible";
}
}
}
}
</code>
# August 18, 2005 4:03 AM

Sébastien Ros said:

I tried Jade one time ... and I was killed by a bomb from a boat ... never tried again ;) The CD is still beside the xbox

I like Soul Calibur 2 pretty much as I can fight with my girl friend!

But the game where I spent most of my gamer time was on Starcraft, in multi player mode.
# August 18, 2005 3:03 PM