Explore possibilities of using data binding in HeuristicLab (parameter binding)

[abeham]

It should be possible to define binding objects that can be attached to a parameter and that will manage keeping the parameter's ActualName and/or !Value up to date with another parameter.

Or in other words: Judith is a programmer developing HeuristicLab problem and algorithm plugins and she just hates writing a ton of UpdateX, ParameterizeY methods and create dozens of event handlers to make sure any change doesn't break the configuration of her problem or algorithm.

Alan is an HeuristicLab user that likes exploring algorithm ideas. However, he's unhappy that all the wiring magic is lost as soon as he converts an algorithm into a UserDefinedAlgorithm.

[abeham]

r4745

• Created a branch of the trunk to explore parameter binding

[abeham]

r4757

• worked on parameter binding (wip)

[abeham]

r4758

• worked on parameter binding (wip)

[abeham]

r4770

• worked on parameter binding

[abeham]

r4787

• Updated binding according to discussion
• Added small test case for the TSP

[abeham]

r4788

• Changed event handler cache to be static and keeping the DynamicMethod
• Added case when source property was null
• Added regions to clarify code a little

[abeham]

r4790

• Added detection if a certain link in the chain implements INotifyPropertyChanged (still missing -> fire only on a change to the "right" property)
• Added optional parameter LambdaExpression in the binding
• Changed cloning behavior of binding -> bindings have to be cloned only after the clone is fully constructed

[abeham]

According to epitzer serializing LambdaExpression is an arduous task and hardly possible. He tried to do that initially in the persistence, but gave up on it. He suggested a different way, by using binding transformers that provide a range of configurable transformations with a non-generic method signature object Transform(object). This is unfortunately a much less elegant solution.

Another problem is that the binding mechanism will not work on UserDefinedAlgorithm. It will fail once it tries to navigate over the properties which are defined in an algorithm, but which the UDA doesn't have.

[abeham]

Much of the wiring problem has been solved by other means, nowadays we do have a lot convenient methods for defining new problems (encodings and programmable problem). Users don't always need to write new plugins and we're trying to put into the GUI what can reasonably be done in the GUI with simple interfaces and little code to write.

This branch is outdated, the idea never worked to our expectations, there are still open points. If there are no objections I will close this ticket and kill the branch.

[abeham]

r13559: terminated branch