Null exception management, part 2

Lou; don't spend any time on this. I'll implement it and submit a patch.

The patch (against r256): * Adds a configuration attribute to the compiler element, "NullBehaviour?". NullBehaviour? can be "Strict" or "Lenient". Omitting it makes it default to "Lenient", which makes Spark behave as pre-patch. ** Propagates the configuration to the ** Adds attendant functionality (the fluent interface bits, the parsing bits, the default-value) ** Adds tests to cover these changes * Modifies the behaviour of GeneratedCodeVisitor? (for CSharp; I don't know Ruby or Python syntax for achieving the feature, though I have provided their engines with the same parameter from config) such that now if the configured to be strict, Visit(SendExpressionChunk? chunk) will render C# to throw an ArgumentNullException? instead of swallowing it or rendering the literal to the output. This is intended so that in a development environment, views will fail-fast, and the developer will be forced to correct errors sooner. ** Exception stack trace should be maintained via the overload to ANEx chosen ** Adds tests to cover these changes (to the Castle MonoRail? integration tests only; I'm not familiar with ASP.NET MVC). In so doing, refactored the test-fixture to extract a base class and then use a template method to initialise the view factory under test.

So - just the first thing that I asked for, then ;-)

(In [257]) Applied patch from Pete Mounce Closes #90 Configurable Null exception behaviour

Default is Lenient, which will not interrupt page output. Strict will throw ArgumentNullException? whose message contains the throwing ${expression}. Usage:

<spark>

<compilation nullBehaviour="Lenient|Strict"/>

</spark>

or

SparkSettings? settings; settings.SetNullBehaviour?(NullBehaviour?.Lenient | NullBehaviour?.Strict);