Who should manage the layout of my modular UI (WPF context)?

The easy answer is : “the LayoutManager”. Does layout responsibility rest with the view or controller(ref MVC)? Whose business is it to know about the positioning of modular control xxx and whether it should be visible when an element in modular control zzz is clicked.

How do I make the best use of the MVC triad when I need to precisely manage my modular UI layout.

Do I need a view specific layout controller that is pixel and coordinate aware, perhaps a variation of the MVCC? Should the additional C reside in the xaml code behind or can I weave in the layout rules at runtime? When the scope for cross window navigation is severely restricted what pattern can I turn to?

My current problem domain brings these questions to the fore.

GUI layout tends to be orthogonal to the core concerns of application development, yet it is critical to the success and acceptability of the application. To the user, the UI is the application.

I will be prototyping various approaches to this vexatious issue in an attempt to develop a maintainable approach. At present a finite state approach in which the main actors are the view and some layout policy seems likely.

When everything is a DependencyProperty, life’s a beach…

When faced with a requirement to automatically generate parts of a modular UI based on events raised by interaction with other controls, the question is normally, how do I position the generate controls in such a way that there is no conflict between my design-time view of the UI and it’s runtime view.

Combining the grid layout and use of DependencyProperty resolves this dilemma

public VanillaLayoutTemplate()
{
    InitializeComponent();
    PositionGroupControlsInFirstColumn();
}

private void PositionGroupControlsInFirstColumn()
{
    CaptureOutComeGroup.SetValue(Grid.ColumnProperty, 0);
    ProductServicesGroup.SetValue(Grid.ColumnProperty,0);            
}

The CaptureOutComeGroup and ProductServicesGroup represent a hidden control that is positioned in the first column. When the page is rendered, the 2 controls are overlapped and hidden; visibility is managed by the user providing various inputs.

WPF Toolkit and the DatePicker Control

The journey started out with a hunt for a date control that would form part of the user interface. The core WPF API does not come equipped with this capability so I decided rather than lose precious time trying to build one, I would Google for it.

A download from CodePlex later, I had the binaries  on the development machine and I was ready to rock. Lo and behold…there was none of the precious documentation that us developers have become fat on, but as I soon discovered integrating the control is pretty simple.

I added the new assembly reference to VS2008 and this was loaded as shown below:

The XAML for the integrated control is

<GroupBox Grid.Row="5" Header="Call back notes" FontSize="14" Margin="1,1,1,308" Visibility="Hidden" Name="CallBackNotesGroup">
    <StackPanel Grid.Row="5" Height="218" VerticalAlignment="Top">
        <TextBox Margin="2,2,2,2" Name="textBox1" TextWrapping="Wrap" MaxWidth="300" MaxHeight="120" BorderBrush="Black" Height="100" />
        <Controls:DatePicker>                    
        </Controls:DatePicker>
        <Button Grid.Row="3" Margin="2,2,2,2" Name="button1" FontSize="14" Width="163" HorizontalAlignment="Left">Arrange call back</Button>
    </StackPanel>
</GroupBox>

The rendered UI looks something like this:

 

The control exhibits automatic polite validation behaviour which is activated when an invalid date string is entered in the text box. That’s one layer of validation that I don’t need to worry about!

Generating the lattice from first principles

In an attempt to model the binomial lattice, I will have to generate the lattice data structure and decorate it with various properties(probabilities, prices, node Id’s etc), so I thought I would approach the problem by first generating the node Ids for each time-step. So here we go:

public void GenerateLatticeNodes()
{
    var numberOfTimeSteps = 20;
    var nodes = new Hashtable();
    var nodeId = 1;
    for (var i = 0; i < numberOfTimeSteps; i++)
    {
        var numberOfNodes = i + 1;
        var nodesAtTimeStep = new int[numberOfNodes]; ;
        for (var j = 0; j < numberOfNodes; j++)
            nodesAtTimeStep[j] = nodeId++;
        nodes.Add(i,nodesAtTimeStep);
    }
    //What no test?
}

For the moment this is just a collection of identifiers to which the object richness( the notion of a node having asset price, probability of up/down movement etc) will be added.

The node numbering scheme adopted is such that the initial node is 1 and subsequent nodes are numbered incrementally in an up/down fashion.

Probability diffusion in the binomial lattice

Given that we can express the diffusion of asset prices in the binomial tree as a summation of the form

The expected stock price at a given time-step can be expressed in terms of the probability, p, of an upward movement, u, of the underlying asset. Conversely the probability of a downward movement in the asset price is denoted as 1-p, where d, is the amount by which the stock moves down. Hence the expected asset price at the first time-step can be summarised as:

Why the vectors? Well I suppose there is a directional, albeit unidirectional, aspect to the diffusion. We are interested in heading towards the future and ascertaining the expected value of the asset at the expiry date.

The obvious question then becomes, “how do we generalize the findings above for a binomial tree with n time-steps?”

The probability diffusion for each time-step appears to follow the summation above. A few tests should be enough to prove whether this is actually the case.

Modelling the growth of asset prices in a binomial lattice

Why would we want to do this? Well one of the key decisions when pricing call options using a binomial lattice is whether it is optimal to exercise the option or let the option lapse. We need to know whether we are in the money or not. The value of the asset price in relation to the strike price is a good indicator. If the asset is cheaper in the spot market we let the option lapse, otherwise we exercise the option, buy the asset at the strike price and sell it on the spot market making ourselves a tidy little profit :).

Starting at time t=0 and given that the volatility of the asset is d and u, the asset prices for a given time-step follow the distribution:

We then proceed to test the assertion above using NUnit 
(note the syntactic sugar which makes the testing of collections much more direct)

[Test]
public void StockPriceGrowth()
{
    var t = 2;
    var u = 1.1;
    var d = 0.9;
    var initialAssetPrice = 20;
    var stockPrices = new ArrayList();
    var expectedAssetPrices= new[] {24.2,19.8,16.2};

    for (var i = 0; i <= t; i++)
    {
        var stockPrice = Math.Round(initialAssetPrice * (Math.Pow(u, t - i) * Math.Pow(d, i)), 2);
        stockPrices.Add(stockPrice);
    }            
    Assert.That(stockPrices,Is.EquivalentTo(expectedAssetPrices));
}
And hooray we get the greenbar! 

 
The stock price generation behaviour belongs to a utility class responsible for generating the asset prices
at given time-step, so we refactor the test to the following:
[Test]
public void StockPriceGrowth()
{
    var t = 2;
    var u = 1.1;
    var d = 0.9;
    var initialAssetPrice = 20;
    var expectedAssetPrices= new[] {24.2,19.8,16.2};
    var stockPrices = BinomialCalculator.StockPricesForTimeStep(t,u,d,initialAssetPrice);
    Assert.That(stockPrices,Is.EquivalentTo(expectedAssetPrices));
}

Generalising the binomial lattice for pricing European options

As luck would have it, I am now building a binomial lattice pricing model that employs the concepts of risk neutral valuation, risk free rate and expected option values at a given time step. I am approaching the problem from a computational angle; I am investigating the computational efficiency and complexity of the resulting algorithm as well as the parallelizability of the code. For each node in the lattice I aim to calculate the polynomial representing the probability function. Summing these node polynomials for a given time step and applying backwardation should yield the net present value of the of the option. The scope of this investigation is limited to European call options, but with more work I should be able to extend this to price American options.

Southern Railway broken payment processing workflow

Just how bad does it get? It seems the failure of the train system is really systemic. How could this happen on a live site that takes payments? It does not fill me with a lot of confidence; I guess the passwords are probably stored in clear text in the database.

This little episode transpired whilst I was trying to purchase a season ticket(annual train ticket). It happened right at the end of the workflow. The culprit: a missing include file; does this stuff ever get tested. Just because it works in the dev environment does not guarantee that it will work in the live.  You would have thought that the deployment process, plus configuration management and the army of QA testers would have caught this, but it seems they never made it into the office due to the snowy conditions. Sigh.

Automated unit and functional tests would most probably have created visibility of this issue.