It's been a while since the last update, and I think it's worth mentioning that ASP.NET 2.0 support in Mono will get much, much better with the upcoming 1.2.4 release. The release notes contain a bit of information but there is a lot of little changes hidden behind the bigger ones. Most of work in the past months went into fixing small incompatibilities that were popping out all over the map.
One of the most important highlights of the next Mono release as far as ASP.NET is concerned will be, in my opinion, the fixing of an XSP problem with overlapped requests that resulted in exceptions thrown and requests failed. It took a fair amount of testing to pinpoint that one, but it's gone. In addition, ASP.NET performance has doubled for 2.0 applications, mainly thanks to getting rid of heavy-weight code to detect whether the visiting browser supports JavaScript.
The new code relies on the idea that the browser's UserAgent string (as unreliable source of information as it is - but we have no other choice) can be used to detect similar browsers with enough accuracy to "check" if JavaScript is there or not. New utility, called cuplevel (CompileUplevel) was added which takes an XML description of JS-capable browsers and compiles it into ugly, but fast, matching code. The code is able to match over 90000 of unique UserAgent lines in less than 0.02s, which is quite fast.
To make sure that our JavaScript scripts still work correctly, the checks for ECMAScript and W3C DOM capabilities have been moved from the class library to the scripts themselves (where they really belong). This may result in small parts of the script not working on certain browsers, but the rest of the script will continue working - unlike previously when no script was ever output to the client if the class library failed to detect that ECMAScript is supported.
In a word - do try 1.2.4 when it's out (or even grab a copy now), test it with your favorite 2.0 application and file reports on any bugs (even the smallest ones) you can find!
Subscribe to:
Post Comments (Atom)
4 comments:
Will these new changes work with, for example, a Firefox browser with JavaScript disabled? Or a Firefox browser with the NoScript extension enabled?
Regards.
Nothing changes in this regard, the check is just shifted from the class library to the script. The check belongs in JS anyway, as it can easily test whether the required features (e.g. the Regex class we use or document.getElementById function) are present, and the check is more reliable than one based on UserAgent string parsing.
If JS is disabled, or if NoScript is enabled then no JavaScript is executed at all anyway, so there's no problem here.
The thing to note is that MS.NET generates JavaScript (e.g. for postbacks) even for browsers that do not have JavaScript support or have it disabled (tested with e.g. Elinks). Currently we do the same, but it is bound to change in some near future.
I know you do this to have compatibility with Microsoft's ASP.NET implementation, but would it be possible to work with Microsoft so that ASP.NET in the future may deprecate and remove all of this browser sniffing nonsense? Because it is really nonsense and does not belong in a framework like ASP.NET.
Anything is possible :) But the thing is - we need to detect whether or not a browser supports JavaScript and what level of support is available (e.g. whether it has w3c DOM support, ECMA script etc.). The "sniffing" needs to be present at least in the javascripts used/generated by the framework. In that sense, the detection does belong in ASP.NET. What does not belong there, and here I agree with you, is the class library knowledge of JavaScript. My opinion is that the class library should generate JavaScript regardless of whether the visiting browser knows what to do with it and leave the rest to the scripts themselves.
There's one exception to it, namely the postbacks. Both class libraries use JS to post the forms back to the server and we need a way to detect whether or not JS is there for us to handle the task. I've been thinking about it for a while and the best I could come up with (so far) is to unconditionally generate buttons to post the form and then replace the code using DOM manipulations if the browser supports JS+DOM.
This approach is better to what we use now, but has its drawbacks (in relying on the fact that the browser supports DOM with JS).
Post a Comment