Let me explain one more time why the Atlas compatibility layer works this way...

re: Let me explain one more time why the Atlas compatibility layer works this way...

Bertrand Le Roy — Wed, 31 Jan 2007 05:14:06 GMT

Ali: please contact me through the contact form of this blog.

Atlas Timer is not working in Fire Fox

Ali Muhammad — Wed, 31 Jan 2007 04:01:08 GMT

Dear freinds,

I have a web application developed in vb.net. I use

Atlas Timer control to update my update panel . This application working fine on internet explorer but not envoking timer in fire fox... any buddy hving clue kindly help me

Regards

Ali.

DOM events in the Microsoft AJAX Library

Atlas and more — Tue, 07 Nov 2006 00:26:44 GMT

In previous CTPs, the client-side DOM event model was the IE model. You would use attachEvent and get

re: Let me explain one more time why the Atlas compatibility layer works this way...

Colin — Tue, 15 Aug 2006 19:13:51 GMT

That's very good to hear! I'm consistently impressed by the overall coolness of Atlas and am excited to see it grow. There are a few kinks to work out, but I have no doubt the Atlas client libraries will eventually wipe the floor with other AJAX/JavaScript frameworks.

re: Let me explain one more time why the Atlas compatibility layer works this way...

Bertrand Le Roy — Tue, 15 Aug 2006 18:03:23 GMT

Colin: these are great points. We had arrived to the same conclusion about the extensibility of the model. The new solution we're developing is more conventional and won't perform as well, but it will be easier to add new browsers even if they don't provide good extensibility points.

Fortunately, Atlas did not ship yet, so we can still take user feedback into account and revise what seemed to be good decisions at the time.

re: Let me explain one more time why the Atlas compatibility layer works this way...

Colin — Tue, 15 Aug 2006 17:27:03 GMT

I really think you made the wrong decision with the compat layer and all the window.event stuff. If you're not going to adhere to standards, and you're creating such a rich, proprietary javascript API anyway, then why not have a new function for observing events like the Prototype Framework does with Event.observe()? Basically you're asking developers to learn a beautiful library which introduces things like inheritance, Atlas XML script, etc. Asking developers to learn two new functions: observe() and stopObserving(), for example, would be extremely trivial. Also, I think your worry about changing the entire code-base upon introduction of a new browser is unwarrented. A properly engineered system can simply provide self-registering strategies which would require no change to the code-base, only a new strategy file. E.g. //expose some function like: Atlas.MapEventModel( browserEventStrategy ){} Assuming that each browser/compatibility strategy implements the proper contract, all the functionality needed to map DOM events to the Atlas framework would be taken care of compositionally in an extensible and maintainable manner. As it is now, you're claiming that the reason you implmented the compat layer the way you did is because other browsers are extensible in ways IE isn't. This implies the assumption that any new browser that comes out will be as extensible as the rest which is very very dangerous. What if a browser comes out that doesn't allow you to hook up window.event? It's very possible! The suggested alternative, on the other hand, is more likely to be able to work around the quirks of browser/capability event incompatibilities present and future. Event handling would happen through a consistant interface that is easy to learn, and the underlying details of providing the mapping to the consistent interface would be properly encapsulated into files such that each are independently updatable and easy to introduce as new browsers with different capabilities come along.

Blog Spotlight - April 8 to 14

Jeff W. Barnes — Mon, 12 Jun 2006 20:18:15 GMT

A lot of cool stuff on the wire this week:

Consequence of leaving debug="true" enabled
Rick Strahl...

re: Let me explain one more time why the Atlas compatibility layer works this way...

Bertrand Le Roy — Tue, 02 May 2006 16:54:00 GMT

Kris: that's only the theory. I really wish it was true but it's not. The standard implementation is incomplete or inconsistent in *all* browsers (although I agree that IE6 is the worst on that point (but on the other hand, it implements non-standard stuff that's absolutely necassary like pixelLeft and that other browsers are slowly implementing despite the non-standardness because they are just useful and were oversights of the standards but I digress)). The incompleteness can especially be felt in Safari (example: the lack of onload event on all elements) and the inconsistencies comes from the fact that many standards are vague in places and open to interpretation.
Plus, the 5% you're talking about is a huge number for us as framework developers who need to make it as easy as possible for third party developers to develop new components. These 5% (or whatever is the real number) is precisely what we need to abstract. These are very complex problems that the average developer just hasn't time to investigate and solve. Look at how complex it is to get the pixel coordinates of an element relative to the top-left corner of the page. It is absolutely necessary to abstract that. Look at the differences in the event models (IE is the one that's wrong here of course but I don't care about who's wrong, I just need to fix it). We just can't constantly deal with two incompatible event models, we need to make that consistent.
It's absolutely true that there are already other libraries out there that do a good job at cross-browser support but you need to take into account that:
* they all have some form of compat layer even if it's implemented differently.
* they do a lot less than Atlas (none of them do anything like xml-script for example).
* Atlas has constraints that other frameworks don't have (such as back-compat with ASP.NET, including third-party controls).
* Atlas is not even in beta state. We're fixing bugs actively.

Standards will help you

kris — Tue, 02 May 2006 13:41:00 GMT

hi,

i still don't understand why there is a full blown compatibility layer in Atlas. javascript, (x)html, css ... are all well defined by the w3c.

so if you use the standards (as they should be used) it will work in any modern browser. i'd say only in 5% you will have to to a dirty trick to make your scripts work in ie. because ie6's implementation of standards is quite poor.l

also there a so many opensource js libraries that already figured out the flaws of ie and correct them. just take a look at dojo, prototype, script.aculo.us, behaviour.js and so on. why reinvent the wheel?

regards,
kris

ps. i dont want to be rude.... just a little provocation with a hope of getting answers :)

re: Let me explain one more time why the Atlas compatibility layer works this way...

Bertrand Le Roy — Wed, 19 Apr 2006 20:33:00 GMT

Andrey: there is support for the IE event model in general (attachEvent, detachEvent, window.event, etc.) but not for specific events for the moment. We may add these in the future if there's enough demand for it.