Andrew Stopford's Weblog

A better treeview, using.....the treeview

After running into the display issue with the treeview and display issues in FF I was looking around for an answer and came across CssAdapters for ASP.NET. This project (currently in beta but would be great to see released) allows you to adapt how controls render, for example treeviews render as tables (which explains the cross over issues with panels and FF) but using this you can adapt to use CSS instead. The installer installs a asp.net template into VS and you can use that website project as the basis for your adaptions. It's wrapped up in masterpages and sitetemplates so if your not using those then you will need to do the following.

• Copy the JavaScript folder over to your site as is
• Copy the arrow, blank, collapse, expand graphic files and TreeView.css, TreeViewExample.css files from the template folder to your site.
• Copy the Adapters folder in the App_Code folder to your sites App_Coder as is.

You will need to adapt your treeview as well, if your not using skins then you will need to alter the treeview with

 <asp:TreeView ID="TreeView" Runat="server" ExpandDepth="4" CollapseImageUrl="collapse.gif" ExpandImageUrl="expand.gif" NoExpandImageUrl="blank.gif" CssClass="TreeView-Skin-Root" CssSelectorClass="PrettyTree">

Here note the CollapseImageUrl, ExpandImageUrl, NoExpandImageUrl, CssClass and the CssSelectorClass. This last attribute is added by the adapter.

Atlas pangs and that ^%$£" treeview again

Working with the collapsible panels in Atlas (and why is it I don't seem to see many examples of asp.net controls in atlas panels) and ran into a few bugs, one I have logged here. I have run into problems with the UpdateProgress control, if it's parent UpdateDatePanel is wrapped in a standard Panel and it's visability is set to false you get JS error's. Lastly if you wrap the TreeView in a Panel, add a load of items, then add a second Panel and (for example) a button. Open it up IE, looks good, open in Firefox, sigh :( When this stuff works, its great when your having to hack at every turn it's horrid.

Atlas tab strip, now with Async callback

Alan has updated his tab strip with simpler js, cleaner css and async callbacks, whoop, whoop!! Been using this on a project and loving it, one thing to watch is if your using master pages is to alter the css so Tabs becomes ctl00_Main_Tabs. In the js make the same change as well as change the selectTab call from selectTab($('FirstTab')) to selectTab($(ctl00_Main_FirstTab')).

Jon on Subsonic

Aspx TreeView's are a pain in the %&$* i

This might having something to do with the fact I have been coding non-stop for 10 hours or so and its past midnight but I have run into an issue with asp.net treeviews that I just cannot solve. While I can bind a treeview to a datasource fine it seems to be caching the data and I have no way of stopping it (I know it's the cache as a quick edit to the web.config solves the problem), I really don't want my data cached, any clues on stopping this?

Update: Moment of "Doh!", thanks Scott for offer of help and also thanks to Arnaud for the suggestion, one line fixes are great and frustrating as heck when it was staring you in the face - long code session hazard :(

Coding to MVP but I need more

I have spent all day today coding a asp.net app to the MVP pattern and it's been an interesting exercise. It's a different way of thinking when developing in contract terms and can feel a little longer winded than normal, the ability to abstract the view and test the presenter makes it all the worth the while. What strikes me is that webforms is not a great for patterns and I hope it gets better at it both for MVP and MVC. In an ideal world it would be great to see

clean abstraction between my view and the presenter/controller.
the presenter or controller to be created as a normal class and unit testable like any other class
for the asp.net controls to use more lower level controls at their base, I don't need to create a IContext because the HttpContext inherits from a Context object that I can expose to my tests.
The event rigs to be built into the framework, currently you have to expose event handlers and re-raise the events for each control event. This boils down to the view being a pure view and the code behind a pure controller or presenter.

A very long road

Roy points out Will Shipleys post, Will I have a few things to say.

Unit testing will help you write better software, in Agile TDD you have one of the powerful development tools are your disposal. Testing does not stop and start at unit testing, it takes on board functional, system and UAT testing as well. To suggest that only you can test a software product and do so by resorting to bashing the keyboard suggests someone that does not understand that such a test cannot be repeated (if such a process was to find a bug, how could you fix that bug and know 100% that your orginal test will check that your fix has worked). It also indicates that with no unit tests how can code be refactored or altered with out the fear of introducing new bugs or breaking old code.

To document your test cases to repeat your tests means manually running through each one for every change you make, what happens if I have 500 test cases? With a unit test suite I could test one level and with automated functional testing the next level and it can do in it seconds, leaving me free to fix the next bug.

Beta testing is a great way of testing, but it should be the last level of testing not the first. Sure enough humans can find bugs and can test things in ways your test suite cannot but your assuming that bugs will be logged and that humans can test every single little thing. With a test suite your testing every single nook and crany of your code, shipping a stable product that your beta testers (and lets face it potential customers) can use with out it crashing. They in turn can report any finge issues that you can feed back into your test suite (thats the aim so you can fix and test and not send it back to the customer broke again). Any thing less than this and your going to give your customer a bad picture of your product, any rational response to this should be

I CARE

ActiveRecord is the answer

In my last post I pondered how a ORM and Sprocs fit in, for me a database that is in at least 4nf and has 1 to many relations with the data is going to need joins in it's queries and its really the issue of the mechs of a decent TSQL sproc that was chewing me the most (queries with joins, in's etc).

When I mentioned this to a friend we started discussing Rails and ActiveRecord and it was with the edition of AR on-top of a ORM that it all become clear. With AR you have a high level of obstraction to define how your ORM mapped objects relate.  The AR and ORM create the queries and joins for you, an example here and another example here (as a side here's an interesting post on why AR in Rails matches, or not, to CF). Going back to the .NET world the only AR\ORM implementation I know of is the mighty Castle project's ActiveRecord which maps a AR pattern to the NHiberinate ORM. Not sure if you can do the same sort of thing in terms of joins, in's etc with Castle as you can with Rails, prehaps the Castle guys could comment.

O/R mappers/Sprocs

IContext, good or bad

One of the comments in Phil's post on using the MVP patten is mapping the Context object to a type that is based on a IContext pattern. For an example of what this does take a look at the interface here and its creation here (CreateContext method). It feels wrong me to though as your adding the request and response data to a collection and getting at the data that way and it seems to go from one object layout to another. I guess that for unit test purposes (mocking the data that this contains for example) this would be useful, am I right in my thinking here.