Habanero Faces has the Capability to Dynamically generate User interfaces. This is a powerful mechanism that if used correctly can result in the developer having to do very little maintenance of his/her User interface and No Dragging and dropping. The way that this is achieved is via Control Mappers. A Control Mapper maps a property or relationship of the Business Object to a Control on the User interface and will handle all updating and communication between the control and the Business Object. Think of it like binding on steroids. For more info on Control Mappers check out the Habanero Wiki  on Manipulating User Interfaces as well as Peter’s article Dynamically Generating User Interfaces.

TDD (Test Driven Development) is an amazing Software Design and Development methodology that revolutionises the way that you build Software.

When Doing TDD you are trying to Isolate your SUT (System Under Test). To do this you typically create Test Doubles (see previous blog) either automatically with a tool such as RhinoMocks or manually (i.e. you hand code the TestDouble).

When using Microsofts Latest addition to the plethora of IOC Container Unity I kept running into the annoying 'ResolutionFailedException' this is a really frightening error with an obscure error message and it is really not obvious what the problem is.

Peer programming with an Intermediate today and I called my Test Double a xxxxSpy. My Peer immediately asked me why? I quickly ran a survey with several friends who all do TDD and realised that the difference between different types of Test Doubles is not well understood.

Since I am a believer that a common language helps communication I decided to quickly write this blog. It mostly contains references to other peoples excellent writtings on these topics.

One thing we've regularly needed to do is to load and save objects to multiple data sources. One example where this might apply is when your security objects (users, roles etc) are stored in a separate database to your application database. Another example is where you have application data and user preference data - the application data being stored to a centralised database and the user preferences being stored to a local xml file, and you would like a unified interface where you simply save objects and have them go wherever they should.

In Habanero 2.3.2 this can be achieved with a DataAccessorMultiSource.  Here is an example:

So the new Habanero version (2.3.2) is out, and one of the new features is an improvement in loading collections in the form of an IN operator (and its negative, not in).  This works similarly to how it's used in SQL - in fact it gets translated into a SQL in clause if your Habanero app is running against a database.  Here's an example of using it in loading a set of Person objects:

BusinessObjectCollection persons = Broker.GetBusinessObjectCollection( "Surname in ('Wiles', 'Powell', 'Naidu')"); It's a really intuitive syntax because of its close relation to SQL's in statement.  Also available is the 'not in' operator which does exactly what it says - searches for items not in the given list.

If you want to load using the more type-safe Criteria objects, or you are using code to build up your criteria clause, you can do it like this:

object[] values = new object[] {"Wiles", "Powell",...

Learning to write good tests can be hard. There are a lot of things to learn technologies to master and if you have been programming for some time then there are some bad habits to undo.

I train a lot of people to do TDD and have learnt from this that there a few small tricks that will significantly help you write a good test.

This blog assumes that you are familiar with the Red, Green Refactor process of test driven development and have some exposure to a unit testing framework such as NUnit.

I also assume you are familiar with the concept that TDD is not a testing activity but is in fact a design and development activity.

In this blog I go through the parts of what I consider to be a good test.

So, we are starting to develop a project in an Agile, TDD manner and we don’t really want to be concerned with too much other than this object has this property and relates to some other object... because my test that I’m currently writing needs it. I don’t really care how this fits into the whole scheme of things at this stage. The fact that my “Invoice Line” object can only ever exist on an “Invoice” and that the invoice must be associated to a “Customer” in order to be valid doesn’t really concern me at this stage. Although all those other facts are true, they have no relevance to my SUT (system under test)...

Changing the Return Value of a Stub in RhinoMocks.