Enter your email address:

Delivered by FeedBurner

New Bits for Atlas - December CTP

Nikhil and the Atlas team have pushed some new bits at http://atlas.asp.net. They have made an amazing jump forward with their platform. Some of the big changes:

- Partial updates with the update panel control. This lets a trigger action on the client do a virtual post back using callbacks. On the server side you have the rich event and stateful object model you are used to. The server then renders only the part of the page that maps to the update panel in question. This could potentially lead to a postback-less web app. That wouldn't necessarily be my goal, but I would like to get rid of past backs that are on the same page.

- ScriptManager upgrade: The SM has had a major upgrade. You can run it in a new 'runtime' mode that provides the OOP features, without all of the atlas controls and other stuff. That is awesome, because one of my favorite features of Atlas is how they turn JavaScript into a real OO language. The SM can also be used to create references to services, so you don't need to write any more script tags. I thought that this was cool though. Also, although it is still supported, the slash-js format isn't needed anymore. Adding references to your own scripts will now be easier with a singleton-like access to the SM. Also, the SM will now ship with prod and debug script libraries. It will detect the setting for debug in the web.config and load the proper libraries.

- Many of the Atlas controls will be going away, to be replaced with 'extenders'. These will be similar to how you would tack on behaviors to a control. They extend the normal ASP.net controls to provide Atlas functionality, like auto-complete.

Check out the full blog post at .


Atlas Presentations

The Thursday night presentation to CONDG went really well. The only slow part was where we (Michael and myself) relied on too much typing during the code demos. We are presenting the same talk at CINNUG this Tuesay, and plan to modify how much code we write on the fly.

I have found this great Atlas resource on the net. Wilco Bauwer has posted a tool that uses to reflection to help document the framework. This has been a great help to me in trying to learn Atlas, and get it to do what I want. It also helps in findig the holes in the current bits. For example, there isn't a server side service manager component yet. You still have to use the client side control. Wilco also some great Atlas postings on his blog as well.

I will soon publish the slide deck, code, and resource URLs on the related user group sites soon. When I send them out to the UG owners, I will post them here as well.

I have found some conflicts when you put a hyphen in the ID attribute of the atlas:panel server control. Hopefully that will be resolved in the next set of bits.

Once I get a good sample app put together, the next feature I will implement is using BizTalk web services to process some rules from the web client.

On another note, there are several good AJAX frameworks for .NET floating around out there. Dave and James say that Ajax.net is a really good one. I haven't worked with any besides Atlas, and I don't plan too. As Atlas rolls into procuction, it will become the defacto standard, with other controls and parts of ASP.NET built to leverage this. Since part of my app will already be using ATLAS, I don't want other parts to use some other framework. Consider Infragistics controls for example. Several of them (including the grid and tree) use their own AJAX pipes to connect to teh server. I can see this raising conflicts, as well as bloating the client side code with more and more javascript references and frameworks. Hoepfully Infragistics will migrate their stuff over to Atlas, when Atlas is ready. We shall see.


Speaking at CONDG about Atlas

I will be speaking at CONDG (Central Ohio .NET Developers Group) on 12/8/2005, from 6-8p. We will be going over Atlas, and looking at some code. I will be bringing along Michael from my team, who is an amazing young developer, to be my code monkey. Drop by if you have time.

TDD for BizTalk

TDD is the hot new topic. Actually, it has been around in one form or another for several years. With the release of Visual Studio 2005, I expect to become even more of a hot topic. When I introduce TDD to professional developers in my shop, they tend to think of it as a drag at first. This is when I usually ask them how they developed their last personal project. They always talk about how they wrote on feature, and made sure that worked, and then moved onto the next piece in a very organic way. They grew the architecture as needed, and refactored to streamline the code. They didn't sit down and write 50 pages of technical documentation (although they may have drawn some big boxes and arrows.) TDD is merely writing tests to validate the features you want to implement, before you write the code. The green light of TDD is what tells you when you are done. Which is hard for some developers to know. We call them 'gold-platers' around these parts.

Test Driven Design is a great tool to use on your development team. We use it my shop, in one form or another. This process does leave you with a complete suite of tests to support your code. The true soul of TDD though is the concept of incremental design. By writing a test for a specific business rule or requirement (sometimes many tests), and then writing JUST ENOUGH code to complete that test, you will end up with a much tighter and appropriate design. The toughest part is building something before you truly need it. Don't confuse this however with the use of patterns to build in flexibility that might be required of the system; such as the provider model seen in many parts of ASP.NET 2.0.

This post isn't really about TDD in software, and I may not be the highest authority on it to begin with. The challenge with our shop is the big part of software that can't be supported by TDD tools (ie nunit). For example, it has been hard to automate and drive out our design of BizTalk orchestrations without any sort of normal TDD tool. This is where BizUnit comes in. It gives you the same toolset for BizTalk that you would have with your normal business code. The best way to approach this is to consider your processes in BTS as black boxes. Then you can use BizUnit to submit messages, and validate their results. Version 2 was just released at its workspace. I look forward to upgrading to version two. We are at a point in a project at the shop where there will be some significant BTS work, and this will make it much nicer.