Saturday, December 3, 2011

Putting the pieces together - the DSharp presentation model

Recently there have been several threads and discussions about separating GUI and business logic. Of course that is nothing new, the MVC or MVP patterns are widely known. There is just one problem especially with these two patterns: the dependency between the presenter or the controller and the view and model. Often you cannot easily change the view. Testing the model and the controller or presenter without the view is complicated or impossible.

This is where the MVVM pattern has its benefits. Of course in WPF this pattern can shine because you have XAML but also in Delphi this pattern is worth a closer look. This pattern is also known as Presentation Model. The main benefit over MVC or MVP is that view and viewmodel have no dependency on each other. You can design the GUI independently from the business logic and just bind them together later. And there is the keyword that makes this pattern work: binding.

There are several amazing frameworks for MVVM development in .Net like Caliburn Micro or Prism. Caliburn consists of several different pieces to easily build applications the MVVM way. One of them is the ModelViewBinder. It takes the view (like a form or a frame) and a viewmodel (like a datamodule or another business object) and creates bindings to connect these two using naming conventions. For example the Lastname property of the viewmodel is bound to the Lastname edit on the view, the Orders property which may be a list gets bound to a listview called Orders. You could also bind the Customer.Address.Street property to the Customer_Address_Street edit on the view. All this gets powered by a DI container that puts all the pieces together, also by convention over configuration. If you have a viewmodel called CustomerDetailsViewModel there should be a CustomerDetailsView (there are actually several different conventions and you can add more if you like).

DSharp presentation model makes it possible to use the powerful spring DI container and data bindings to easily build applications that are easy to test and to develop. It sure is just scratching the surface yet but when you take a look at the ContactManager sample in the svn repository you can get a basic idea of what is possible.

Enough with just talking theory. Let's create a simple application!

Step 1 - The View

After creating a new VCL application (FMX is pretty similar - there are just not that many controls supported out of the box yet) we add some controls on the form so it looks like this:


After saving the unit the source looks like this:

unit CalculatorViewForm;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, DSharp.Bindings, DSharp.Bindings.VCLControls;

type
  TCalculatorView = class(TForm)
    BindingGroup1: TBindingGroup;
    CalcOperator: TComboBox;
    CalcResult: TEdit;
    Calculate: TButton;
    Label1: TLabel;
    LeftOperand: TEdit;
    RightOperand: TEdit;
    Error: TEdit;
  end;

implementation

{$R *.dfm}

initialization
  TCalculatorView.ClassName;

end.

The only thing you actually have to write there after adding the components including the binding group is adding the unit DSharp.Bindings.VCLControls.pas (only if you don't have DSharp bindings VCL designtime package installed which inserts that unit automatically) and the line in the initialization part of the unit. This is necessary so the linker does not remove this class because it actually is not referenced anywhere (similar to the RegisterComponent you do if you are working with the DI container in the classic way).

Step 2 - The ViewModel

Now we create the viewmodel - the class that actually does the work and holds all the states of for the UI.

For our simple calculator we just need some fields and a method:

unit CalculatorViewModel;

interface

uses
  CalculatorInterfaces,
  DSharp.PresentationModel.ViewModelBase,
  SysUtils;

type
  TCalcOperator = (Add, Subtract, Multiply, Divide);

  TCalculatorViewModel = class(TViewModelBase, ICalculatorViewModel)
  private
    FLeftOperand: Double;
    FRightOperand: Double;
    FCalcOperator: TCalcOperator;
    FCalcResult: Double;
    FError: string;
  public
    procedure Calculate;

    property LeftOperand: Double read FLeftOperand write FLeftOperand;
    property RightOperand: Double read FRightOperand write FRightOperand;
    property CalcOperator: TCalcOperator read FCalcOperator write FCalcOperator;
    property CalcResult: Double read FCalcResult write FCalcResult;
    property Error: string read FError write FError;
  end;

implementation

{ TCalculatorViewModel }

procedure TCalculatorViewModel.Calculate;
begin
  try
    case FCalcOperator of
      Add: FCalcResult := FLeftOperand + FRightOperand;
      Subtract: FCalcResult := FLeftOperand - FRightOperand;
      Multiply: FCalcResult := FLeftOperand * FRightOperand;
      Divide: FCalcResult := FLeftOperand / FRightOperand;
    end;
    FError := '';
  except
    on E: Exception do
    begin
      FError := E.Message;
      FCalcResult := 0;
    end;
  end;
  DoPropertyChanged('CalcResult');
  DoPropertyChanged('Error');
end;

initialization
  TCalculatorViewModel.ClassName;

end.

We inherit from the TViewModelBase class which has some mechanics built-in that we need for the whole thing to work (like inheriting from TComponent which is necessary for the lifetime management and implementing several interfaces the framework needs). If you are just interested in creating something similar to the passive view and constructing the classes yourself and just using DSharp bindings you can just inherit from TPropertyChangedBase or some other class and wire things up yourself (or use the ViewModelBinder to do that without the rest of the framework).

We actually have no setters for the properties in this viewmodel because the changes just happen when you click the calculate button. Did you notice we named the properties exactly like the controls? That is not by accident. As I told you earlier the ViewModelBinder looks for components and properties it can bind together and it does it by their names.

One thing here is not obvious. We added the 4 operators to the items of the combobox earlier and we named them exactly the same (not the classic hungarian notation for enums here though). This is because the ViewModelBinder binds to the Text property of a TComboBox (you can change that to ItemIndex if you like - just edit the line in DSharp.PresentationModel.VCLConventionManager.pas). Then you can name the enums and the items differently. This may also make more sense when you localize the items in the combobox but it depends on how the combobox is set up. In the future the ViewModelBinder might consider the options of the combobox.

The calculation method is actually pretty simple. At the end it sends the notifications of the changed properties: CalcResult and Error. Keep in mind that this example does not show any kind of validations. You can still write rubbish into the edits. Since internally a conversion is done from string to double (bindings have a default value converter unless you specify one yourself) the value is not sent to the viewmodel if the converter cannot convert it into a double. How validations can be done and shown in the UI can be seen in the Validations sample.

Now let's take a look at the last unit of this example:

unit CalculatorInterfaces;

interface

uses
  DSharp.ComponentModel.Composition;

type
  [InheritedExport]
  ICalculatorViewModel = interface
    ['{03AF7AE1-CCDF-4F06-9074-919F6C759DBE}']
  end;

implementation

end.

The InheritedExport attribute tells the DI container to register every class it finds that implements this interface. That is why we had to add the line in the initialization part of the viewmodel unit. Because that class also is referenced nowhere and the linker would just throw it out. Why not doing the registration of the class there instead? That would actually create a dependency on the DI container and you have no chance to remove that registration for unit testing without code changes.

Remember to add a guid to the interface, otherwise the DI container will complain.

But wait - that interface does not have any methods. Yes, for our example it actually does not need them. Because bindings currently can only work between objects the interface is cast to the implementing object behind the scenes. Keep in mind that you cannot do interface delegation and binding to such interfaces. Also in our example we don't call anything on that interface because the Calculate method (of the object) is bound to the button. For a more complex scenario and actually using the interface methods look at the ContactManager example.

Step 3 - Putting the pieces together and starting up

Let's take a look at the dpr file now:

program Calculator;

uses
  Forms,
  CalculatorViewForm in 'CalculatorViewForm.pas' {CalculatorView},
  CalculatorViewModel in 'CalculatorViewModel.pas',
  CalculatorInterfaces in 'CalculatorInterfaces.pas',
  DSharp.PresentationModel.VCLApplication;

{$R *.res}

begin
  Application.Initialize;
  Application.Start<ICalculatorViewModel>;
end.

We have to make some modifications here. By adding the DSharp.PresentationModel.VCLApplication (or FMXApplication) unit we add the Start<T> method to TApplication. That is the method that starts it all up as the name implies. You have to specify the root viewmodel of your application. From there on you can build everything you like - manually or using the presentation model. We removed the other methods except Application.Initialize. I have to admit that I am not totally happy with that solution right now because it kind of breaks something in the IDE regarding editing the project options (only things like Title that result in the IDE editing the dpr file). Everything else still works, no worry. The Initialize call has to stay there because removing it would actually remove the theming from the application (another weird thing related to the source of the dpr file).

Let's start the application and look if it works (if you don't want to do all the steps by yourself you can find the source in the repository as always). For now I am not going into the implementation details - I leave that for a future post to explain how all the different pieces are working together to make it a bit clearer and less "magic".

DSharp presentation model is available for Delphi 2010 (without aspects) and higher (working on 64bit for XE2) - if you experience any problems feel free to send me an email or file an issue on the project page - I usually test it on all platforms but sometimes some of the nasty compiler or rtl bugs may break something.

Saturday, October 22, 2011

CodeRage 6 feedback and DSharp news

I think Code Rage 6 had interesting stuff for almost everyone. Thanks to the time difference I could watch the sessions live that interested me most at home after work (as I was also very interested in the Q&A):

LiveBindings (Jim Tierney)

You know I have been complaining about the LiveBindings much in the past. So the questions I had prior to these sessions were: Did I miss something when I started working with them that affected my opinion so negatively and what is the general opinion about those bindings (as the reaction of other people)?

Jim started with some console applications explaining the expression framework beneath the LiveBindings. This session was very interesting and actually motivated me putting some work into the DSharp expressions to use them in the bindings (as I started developing those after I created the bindings). More about that later.

The other two sessions actually had no surprises for me. In fact the Q&A was more interesting. Unfortunately I forgot to save the log so I have to recapitulate that from memory.
Someone asked the question I was expecting: Why using LiveBindings over the traditional way since it looks very complicated setting them up (especially when working with grids and lists). It may be just my point of view but Jim did not have the killer argument. Sure, he mentioned the separation of GUI and BL but hey it is more than that.
If easy and painless to configure bindings can completely take care of your data flow. You just have to care about computing it. Think about how much code you have written in the past to show data, get it from one place to another and much more. Almost all of that code can be removed with a good binding system or at least moved to another place where it is not in the way. When asked about things like property references his answer saddened me - there are no plans for something like that. I still hope he just did not know about it.

Dependency Injection and Unit Testing (Nick Hodges)

On Wednesday I was excited about Nicks sessions and I have to say it again: very well done, Nick! I think these two sessions got people interested in learning more about dependency injection and as I have said in the past: recent releases since 2010 (with introducing the enhanced RTTI) over XE (first version that I did not want to throw out of the window when heavily using generics) to XE2 (more bugfixes and more features for the RTTI like virtual interface - also more on that later) gave us the possibilities other languages as C# or Java have had for ages. Using modern developing techniques to be more productive and raise the code quality.

His second session was about unit testing and I have to admit, I often am more excited about implementing new things instead of testing some existing things. That often has to do with hard to test code (like existing code that respects no clean code rules and is a total mess and has dependencies all over the place). When writing code with testability in mind it actually is fun to write tests, refactor your code and find eventual mistakes within seconds. But what about more advanced unit testing frameworks in Delphi? DUnit has been around for years and with new techniques there is also the need for a more advanced unit testing framework. There are several projects around and as Nick already mentioned it would be great to get the people together to build something great for the community. I just recently read about JBehave and immediately liked the idea.

Also with the possibility to use mocks (I am still a bit jealous that Delphi Mocks by Vincent Parrett is mentioned so often compared to DSharp) there are many ways to use the new features we got in the past 2 years.

RTTI (Robert Love)

As I have been exploring the RTTI since its release Robert could not tell me anything new but his sessions actually were very interesting and inspiring to those that have not touched the RTTI yet or at least not much. There are so many ways using it and actually I already cannot think of living without them.

Actually I found something on friday that was strange - especially with having in mind what Nick did. He put an entire class into the implementation part of a unit registering it to the container in the initialization part of the unit. I mentioned the dependency on the container in that case and tried something else: using TRttiContext.GetTypes to iterate all known types looking for attributes that tell to register that type. But it did not list the class in the implementation part of the unit. The class was not thrown out by the smart linker because it was actually used. It just seems to be the case that GetTypes does not find any types in the implementation part while GetType(...) works.

New things in DSharp

You might have noticed a lot of commits in the DSharp svn repository recently. I have refactored the collectionview classes (those responsable to bind lists of objects to controls) and added some more presenters to work with the DevExpress controls (grid and treelist). The expressions that started as experiment have been improved and are part of the binding framework now. I also moved some units to their own namespace (logging and aspects). And as I mentioned earlier one feature I am very proud of:

DSharp got full AOP for interfaces.

Some weeks ago I implemented AOP for virtual methods that made it possible to patch the VMT of any class at runtime making it possible to inject aspects into every instance of a class, its descendants and every new created class automatically. With the new classes and with support for attributes it is possible to declare aspects and apply them to virtual methods, interface methods and entire interfaces and classes.

I will explain that in detail in a following article as I am currently working on an adapter for the spring DI container to work with my composition and  presentation model which I also will explain in detail soon. For now you can check out the sample and see how easy it can be using aspects like logging on your interfaces, implementing it once and using it everywhere without writing any line of code (well, except the attribute)!

Friday, October 7, 2011

Supports killing objects

Today I had a really bad "d'oh!" moment... feel free to laugh at me because I did not know better. ;)


You all may use the Supports routine - so did I without further thinking about it - until today. I shamefully have to admit that I should have looked at its code and/or the documentation earlier.

What happened? In my bindings I check the source and target objects for special interfaces (f.i. INotifyPropertyChanged). I changed some code and strange things started happening in form of access violations. So I quickly found out that the Supports call caused a Destroy on the object when it did not support the given interface. Looking at the source revealed why: Supports does not only call GetInterface with the given guid, no it also does it for IUnknown causing _AddRef and _Release calls. And we know how that ends on some refcounted object that has the initial refcount of 0.

Actually there is a comment saying: "NOTE: Calling this overload on a ref-counted object that has REFCOUNT=0 will result in it being freed upon exit from this routine." And the documentation says: "Warning [...] For objects that have a reference count of zero, this will result in the object destruction."

Just another reason why Delphi sometimes is a pain in the ass if you are using object references and interfaces. Some may say: "Just use interfaces!" No, I do not want to write interfaces for simple data objects and other things. But I want to use interfaces for certain aspects (f.i. INotifyPropertyChanged). And most important: I do not want my objects getting destroyed if they DO NOT implement the requested interface.

Actually I have no idea why this was implemented like this long ago. Anyway I wrote my own Supports overload now:

function Supports(const Instance: TObject; const IID: TGUID; out Intf): Boolean;
begin
  Result := Assigned(Instance) and Instance.GetInterface(IID, Intf);
end;

If your instance is assigned for sure you just might call the GetInterface method. I know there might be cases where the other Supports returns true and this one not like when having a customized QueryInterface. But in my cases it should solve my problem of instances getting shot in the head by the Supports call.

Let me know if I missed something about this implementation.

Sunday, September 25, 2011

AOP and duck typing in Delphi

AOP - something that fascinated me from the very first moment when my coworker told me about PostSharp. Unfortunately something that was almost impossible in Delphi without the proper knowledge of assembler and all the internal low level stuff. However even with Delphi 7 it was possible to a certain degree to intercept virtual methods using MeAOP.

With the recent additions (namely enhanced RTTI) it became very easy to introduce this feature in a more safe way. However this is nothing compared to a framework like PostSharp which is able to enhance almost everything using IL weaving. Currently you can intercept any virtual method that has RTTI (by default any public/published method). It is very similar to what DynamicProxy does. Delphi XE introduced the TVirtualMethodInterceptor that made it possible to intercept the virtual method calls of an existing object. This is done by creating a new VMT at runtime and attaching it to the object. I went a step further and made it possible to patch any existing class VMT so that any object of this class (and every derived class if you wish) can be intercepted. You can add any aspect to any method you like (if it is virtual and has RTTI). There is currently one built-in aspect for logging which logs entering and leaving the method, all parameters and the result if there is one. You can find a simple demonstration on how to instrument two virtual methods to show logging in the SVN repository.

Did you ever face the problem of having a dependency in your code that you could not remove so simply? Like having that class in your code that is passed around but not being part of your source code so you cannot mock it out? Well you could inherit that class and implement some interface so you just have the dependency on that interface. Yes if that class is not sealed (did you know you can use that keyword in Delphi?). To be honest I haven't seen anyone using this yet (could be because I mostly work with sourcecode written in Delphi 7). But let's say you have a class that is sealed and you want to remove the dependency. You could write an abstract wrapper class and then inherit from it to remove the dependency from your code. Sounds like a lot of work, right?  How about duck typing?





When you look at what duck typing means this is very similar to as if the class implements a specific interface. "Walks like a duck and swims like a duck and quacks like a duck" basically means it got these 3 methods. Like implementing IDuck with these 3 methods. But duck typing does not require the class to implement this interface. Prism got duck typing just recently and DSharp now got it too! (only for XE2 yet, sorry) Of course no compile time support but something similar to what the RemObject guys call soft interfaces and dynamic duck typing mode.

Here is the program from the wikipedia page in Delphi!

program DuckTypingSample;

{$APPTYPE CONSOLE}

uses
  DSharp.Core.DuckTyping;

type
  IDuck = interface(IInvokable)
    procedure Quack;
    procedure Feathers;
  end;

  TDuck = class(TInterfacedObject, IDuck)
  public
    procedure Quack;
    procedure Feathers;
  end;

  TPerson = class
  public
    procedure Quack;
    procedure Feathers;
    procedure Name;
  end;

{ TDuck }

procedure TDuck.Feathers;
begin
  Writeln('The duck has white and gray feathers.');
end;

procedure TDuck.Quack;
begin
  Writeln('Quaaaaaack!');
end;

{ TPerson }

procedure TPerson.Feathers;
begin
  Writeln('The person takes a feather from the ground and shows it.');
end;

procedure TPerson.Name;
begin
  Writeln('John Smith');
end;

procedure TPerson.Quack;
begin
  Writeln('The person imitates a duck.');
end;

procedure InTheForest(duck: IDuck);
begin
  duck.quack();
  duck.feathers();
end;

var
  donald: IDuck;
  john: TPerson;
begin
  donald := TDuck.Create;
  john := TPerson.Create;
  InTheForest(donald);
  InTheForest(Duck<IDuck>(john));
  john.Free;
  Readln;
end.

Notice how this is different from dynamic typing you could do with invokable variants. Like the variants approach the evaluation is done at runtime. But in this case you have more type safety. Instead of just passing a variant to the InTheForest procedure and not having any type safety (you could also write duck.Bark() and compiler would not complain) you only can call methods of the IDuck interface. If the wrapped object does not have the required method (also matching parameters) it throws the not implemented exception.

What is it good for? This can open up certain parts of your application to unit testing and mocking that you could not do before because you had lots of static dependencies that could not be mocked. And of course to show that Delphi is catching up. ;)

Saturday, September 24, 2011

DSharp Bindings vs LiveBindings

I think it's finally time to compare these two things and see which one may fit you better. This is my point of view that may not be completely objective.

When I noticed that there was actually no language support for LiveBindings I was very disappointed. I think without language support you cannot create anything that works much different from how DSharp Bindings work. And actually LiveBindings don't. I could not just change the VCL source code so I had so come up with some "hack" (using the interceptor pattern by including the VCLControls unit that subclasses the supported VCL controls). Of course the guys at Embarcadero had the power to change the VCL classes and that is why they implemented the observer pattern into TComponent I guess. Did you notice that is not that easy to connect simple TObject descendants with LiveBindings? Another thing is that you cannot just connect your Edit to some other component, set up the binding and it works. You still have to write code into your OnChange event because the observer only is activated when you use TBindLink. And this will usually set your edit to read only unless the SourceComponent implements some specific interface. I am very sure the whole BindLink part of the LiveBindings was only for enabling data sensitive controls for FireMonkey (something I have not looked much at yet).

In my opinion for simple bindings like displaying some address or customer Data the point goes to DSharp. It "just works" instead of having to write extra code which should not be required because that's the purpose of bindings.

So what about more complex data like displaying a list of objects in a grid? DSharp does not support any grids yet but it got support for listview, treeview and the virtual treeview. Supporting the stringgrid is on the list and will definitely come. How does it work? Well you just connect your list to the view property of the supported control and you specify a data template that needs to be written in delphi. In fact it turns out to be a bit more complex sometimes. When using the virtual treeview and the treeview presenter you want to specify the columns and then you can bind these columns to the properties of your objects in the list. Have you tried yet to bind a list to some listview or stringgrid using LiveBindings? I have and I failed. To be honest I gave up very quick because this was just so cumbersome and required several string based expressions. Did I mention that the documentation on the new features in XE2 especially LiveBindings sucks? Well yeah my documentation does as well, but I don't have a documentation team working for me, right?

Again DSharp Bindings are focused on doing simple things very easily without locking you out when you want to do more complex things. LiveBindings are very unintuitive to use. I think this point also goes to DSharp.

What about connecting your dataset to some controls? This is something I haven't done since ages (except when working with a grid) but this is where LiveBindings got their power - as I said earlier I think their major task is doing exactly this. Unfortunately the designtime support for this is only enabled in FireMonkey but in VCL you have the DB controls anyway. DSharp just does not support this. I have thought about implementing it but I don't see the point. If you want to use datasets just use db controls which have been working for ages. In FireMonkey you just connect your edit to a field with a few clicks.

Point for LiveBindings.

As you may know there is some expression engine sitting below the LiveBindings that can do some nice things like calculating, concatenate strings and much more. There are built-in functions that can be used (like UpperCase, Round or FormatDateTime). I am happy to tell you that DSharp got an integration with DWS just yesterday. So you can basically use everything that DWS can do in your bindings. From making your text capital letters to doing complex calculations or even evaluating business rules if you like. Since DWS is a real scripting engine you have way more power than the LiveBindings expression engine..

I am very sure with this latest addition this point goes to DSharp.

If you don't trust open source because it may not be continued in the future or does not give you the feeling of safety you may use LiveBindings. Also LiveBindings are ahead regarding designtime support - even if it is kind of cumbersome setting them up sometimes.

For being the "official solution" LiveBindings deserve this point.

So the final score is 3 to 2 for DSharp in my opinion. Again I have not been digging through tons of samples and documentation and since Embarcadero always just shows tons of fancy stuff in FireMonkey, other platforms and so on the documentation on this feature is not very present. I like simple solutions to simple problems. I totally hate full blown over-engineered solutions that are a pain to use in your daily business. And I have the feeling LiveBindings are over-engineered and not well designed. Otherwise they would be easy to use like throwing an edit and a button and the form and make them work, right?

If you like using data bindings in any Delphi 2010 or newer you should definitely take a look at DSharp. Also there is much more in it than just data bindings.

Sunday, September 18, 2011

Pimp your unit tests using mock objects

Have you ever faced the problem of having dependencies in your unit tests that made it hard to actually write a unit test instead of writing an integration test? Often you have that problem with bad designed code that does not follow certain principles. But also with well designed code you might end up having your one class you want to test which depends on 3 other classes which might as well depend on other classes. At this point you actually benefit from well designed code. You can use so called mock objects in your unit tests.

Wikipedia describes them as "simulated objects that mimic the behavior of real objects in controlled ways". Other programming languages like Java and C# are using them for years and in fact also for Delphi there are some mocking frameworks. The problem with the existing frameworks in Delphi are that they either rely on generated code (like Delphi Mock Wizard) or strings for defining the expected method calls (like PascalMock).

In the past I already showed you some cool things I found in Emballo (which was developed in Delphi 2009 before the new enhanced RTTI was introduced). The author used a technique similar to what was introduced in Delphi XE in form of TVirtualMethodInterceptor but in a more limited way due to the lack of TValue and generics. With his permission I used this concept to create a more advanced version of mocking for Delphi. It was also inspired by NMock and in the following I will use the example from their tutorial to show you what you can do with DSharp Mock.

First let's see what it can do and what not. As it depends on TVirtualMethodInterceptor you can only mock virtual methods that can be seen by RTTI (public and published by default). And you can only use it in Delphi XE and higher. If you are using XE2 you can also mock Interfaces that contain RTTI (inherit them from IInvokable or add the $M+ directive) and have a guid.

In the following example I will use classes and virtual methods (the example from NMock uses interfaces but I also wanted to share this with those of you using XE).

We have a very simple scenario: a class (TAccountService) that can transfer money from one account to another using different currencies. The conversion rate is provided by another class (TCurrencyService). Both classes have abstract base classes (TAccountServiceBase and TCurrencyServiceBase). We now want to unit test our TAccountService without using the concrete TCurrencyService class (which does not even is part of this unit test). Let's take a look at the code:

interface

type
  TAccountService = class(TAccountServiceBase)
  private
    FCurrencyService: TCurrencyServiceBase;
  public
    constructor Create(ACurrencyService: TCurrencyServiceBase);

    procedure TransferFunds(
      ASource, ATarget: TAccount; AAmount: Currency); override;
  end;

implementation

constructor TAccountService.Create(ACurrencyService: TCurrencyServiceBase);
begin
  FCurrencyService := ACurrencyService;
end;

procedure TAccountService.TransferFunds(
  ASource, ATarget: TAccount; AAmount: Currency);
begin
  ASource.Withdraw(AAmount);
  ATarget.Deposit(AAmount);
end;

Our currency service base class looks as simple as this:
type
  TCurrencyServiceBase = class
  public
    function GetConversionRate(AFromCurrency, 
      AToCurrency: string): Double; virtual; abstract;
  end;

Now let's create our test method to check if the TransferFunds method works correct.

procedure TCurrencyServiceTest.TransferFunds_UsesCurrencyService;
var
  LAmericanAccount: TAccount;
  LGermanAccount: TAccount;
begin
  LAmericanAccount := TAccount.Create('12345', 'USD');
  LGermanAccount := TAccount.Create('54321', 'EUR');
  LGermanAccount.Deposit(100);

  FMockCurrencyService.WillReturn<Double>(1.38)
    .Once.WhenCalling.GetConversionRate('EUR', 'USD');
  try
    FAccountService.TransferFunds(LGermanAccount, LAmericanAccount, 100);

    Verify.That(LGermanAccount.Balance, ShouldBe.EqualTo<Double>(0));
    Verify.That(LAmericanAccount.Balance, ShouldBe.EqualTo<Double>(138));

    FMockCurrencyService.Verify();
  finally
    LAmericanAccount.Free();
    LGermanAccount.Free();
  end;
end;

First we are setting up 2 dummy accounts and deposit 100 euro on the german account.

After that it gets interesting. We define that the currency service will return 1.38 once when the method GetConversionRate gets called with the exact arguments.

After that we are calling the method we want to test. We are transferring 100 euro from the german account to the american account.

Then we want to check if this transfer went correct. So we are checking if the balance on the german account is 0 and the american account has a balance of 138 us dollars. You could use the regular Check methods of DUnit just like I did at first. Unfortunatly I ran into the problem with comparing floating numbers and the test failed for values that should be equal. This is because the DUnit CheckEquals method doesnt have overloads for all the floating types and it does not take the imprecision into account like for example the Math.SameValue functions. Also they are not easily to read in my opinion.

There is some extension for DUnit out there called DUnitLite that does something similar. Anyway also NMock has this Verify class that makes use of fluent interface syntax to make your checks more readable - almost like a real sentence. Internally it uses the DUnit exceptions so you will see some nice message when your check fails.

You probably already noticed that we were missing the call to the currency service so the transfer went wrong and we only have 100 us dollars on that account. Our unit test is telling us: "Expected: "? = 138" Actual: 100" That is what happens if you convert prices one to one. Good thing we would never do that and we fix that in our method.

procedure TAccountService.TransferFunds(
  ASource, ATarget: TAccount; AAmount: Currency);
var
  LConversionRate: Double;
  LConvertedAmount: Currency;
begin
  ASource.Withdraw(AAmount);
  LConversionRate := FCurrencyService.GetConversionRate(
    ASource.Currency, ATarget.Currency);
  LConvertedAmount := AAmount * LConversionRate;
  ATarget.Deposit(LConvertedAmount);
end;

Now our test runs successful. But there was one more line in our unit test we did not talk about yet. The Verify method checks if all expected method calls were made and none was missing. Any unexpected method call would have caused a failure immediately. For example if we swapped the currencies by mistake.

For the full syntax provided and how to set up mocks look at the sample in the repository. I am working on writing documentation for DSharp (thanks Paul for a Documentation Insight license) so it will be easier for you to understand and use in the future.

I think this possibility of writing your unit tests in a more declarative way without having to write a whole bunch of code just to mock dependencies makes writing tests more easy and less time consuming. Also reading them is much easier because you can just see what expectations are made on the dependencies and you can find out much easier what caused a test to fail.

As usual you find the source in the SVN repository.

Friday, September 2, 2011

Delphi XE2 - heating up the hype: playing the matchmaker for VCL and FMX

To be honest, FireMonkey did not interest me much because of the fact that it is not compatible with any VCL application - says the documentation - actually that's not the truth!

To keep the long story short: You can have both in one! (Disclaimer: I did only a few tests and it worked all fine - actually I have no clue if somewhere it's incompatible but I leave that as an exercise to you).

Just create a new FireMonkey form (2D or 3D, doesn't matter) save it and then add it to your VCL application (just accept the warning). You can create your FMX form instance somewhere and just show it - no problem. But what if you want to create some nice control with animations or something and embed it into your existing VCL form? Well, put a TPanel on your VCL form and include the brandnew unit DSharp.Windows.FMXAdapter.pas after the Vcl.ExtCtrls. Then just create your FMX form somewhere and assign it to the new Form property of your Panel - and boom, there you go.

As I said, I just came up with this and it's mostly untested - but that's the case for FireMonkey anyway, isn't it? So I thought this may be very interesting for a few people - especially those that used VGScene before. So have fun creating your shiny and new FMX forms and use them in your existing VCL apps. ;)

Thursday, September 1, 2011

Delphi XE2 - features aside from the hype: TVirtualInterface

While prolly almost everyone was creating fancy FireMonkey or VCL applications for Windows (32-bit and 64-bit), OSX and/or iOS with Delphi XE2 today I took a look at one of my favorite units in the RTL - System.Rtti.pas.

When you look at the RTL Changes for XE2 you will see a new addition to the RTTI - TVirtualInterface. Along with this comes another improvement: RTTI can finally tell the implemented interfaces of a class (and its ancestors). But back to the TVirtualInterface!

Documentation says: "Provides functionality for remote procedure call marshaling. TVirtualInterface creates an implementation of an interface at run time." Wow, this sounds interesting. Further reading states that it's main purpose is SOAP messaging. A client can consume a service with several methods just by calling them through an interface which then "just calls" the remote methods of the service. I think this is awesome because it leads to clear defined interfaces (literally) when working with remote services or other things that just hide behind the interface and which are not necessary to be known. Other things I say...

Some while ago when I came across the Emballo Framework I was impressed by the DLLWrapper which basically imports exported functions of a DLL and provides them through an interface. Of course there have to be some rules like the calling conventions and the parameters have to match. But you can do define an interface like this:

type
  IMyLibrary = interface
    ['{8B47F556-673B-44D6-8F90-09985B3C53E0}']
    function SayHello: string
  end;

And then simply import a DLL which exports this function and just call it. It was a bit rough and actually only supported a few types and not all calling conventions. So I am very happy to have a tool out of the box that makes it possible to write something like this:

if Supports('MyLibrary.dll', IMyLibrary, LMyLibraryIntf) then
  ShowMessage(LMyLibraryIntf.SayHello());

Those of you that worked with .Net in RAD Studio 2007 may know this - it was called Virtual Library Interfaces. I have not tried yet, but I am sure if you have the correct signature in your interfaces methods you can call almost every DLL. Actually the Supports functions does not exist in Delphi but you can find it in the brand new unit DSharp.Core.Plugins.

I uploaded a simple sample how to use this (including the new unit which can also be downloaded from the svn repository).

I also added the DSharp packages for XE2 today (only 32-bit for now, 64-bit compatibility will follow soon). I know there is some issue with the asm code in the DSharp.Core.Events (that has to go for 64-bit anyway) which break bindings for now - but I am working on it. Also more about LiveBindings vs DSharp soon.

Wednesday, August 17, 2011

LiveBindings - what do you expect?

Since the start of the RAD Studio XE2 World Tour the word is out. Delphi XE2 will have 64-bit compiler, support for OSX and iOS applications with their new FireMonkey GUI framework and LiveBindings. If you haven't read the detailed RAD STUDIO XE2: Launch Event Report yet - now is the time to do it.

When I heared about some built-in data binding architecture for the first time I was very excited. It was just a headword on the roadmap for Project "Wheelhouse" but now we know it will be coming with XE2!

Unfortunately there have been much more informations and speculations about the 64-bit compiler, the support for other operating systems and the FireMonkey framework than for those LiveBindings.

On the official Embarcadero forums there has been some discussion about what to expect. WPF and Cocoa have been mentioned. It has also been mentioned in Auckland that there will be some expression engine to do more than just simply add the TCustomer.LastName property to some TEdit.Text but use some kind of scripting. How will this work? Will there be some designtime support for it to make sure you don't have typos in it (one of the major drawbacks in my current implementation)? Also will the whole binding architecture be supported by new language features to make it save at compile time (like property references or built-in change notifications)?

Lots of questions but only few informations (yet). But we can guess, speculate and wish. So please feel free and leave a comment about what you expect from LiveBindings in Delphi XE2.

Wednesday, July 20, 2011

Property references in Delphi - possible?

What is the worst thing about how bindings can be realized in Delphi? One may argue but I think it's the magic strings specifying what property to bind. I cannot think of any solution that could get rid of that. Using magic strings (and not only in that case) makes your software vulnerable to certain problems. Just mentioning a few:
  • refactoring may break your code
  • typos may break your code
  • no possible compiler checks for correctness
  • no code completion support
Well, a few versions ago we got method references. You prolly know how they are implemented behind the scenes but let's take a quick look at them. You can do something like (as defined in SysUtils):
type
  TFunc<T> = reference to function: T;
As you also may know this is a reference counted type. Guess how it is implemented? Correct, with an interface. This is similar to:
type
  IFunc<T> = interface
    function Invoke(): T;
  end;
You can even use those method reference types as Interface when you implement a class:
type
  TMyFuncClass = class(TInterfacedObject, TFunc<Integer>)
  public
    function Invoke: Integer;
  end;
Or you can inherit your interface from it (and of course implement that interface into your class):
type
  IFunc<T> = interface(TFunc<T>)
  end;
Ok, but we were talking about properties, right? Well a property basically is not much more than the combination of a function and a procedure - the getter and the setter.
We could define it like this:
type
  IProp<T> = interface
    function GetValue: T;
    procedure SetValue(Value: string);
    property Value: T read GetValue write SetValue;
  end;
So it is nothing more than (of course this does not work):
type
  IProp<T> = interface(TFunc<T>, TProc<T>)
    property Value: T read Invoke write Invoke;
  end;
But what you can do is this:
type
  TProp<T> = class(TInterfacedObject, TFunc<T>, TProc<T>)
  private
    function Invoke: T; overload;
    procedure Invoke(Value: T); overload;
  public
    property Value: T read Invoke write Invoke;
  end;
We can take this and use it as property reference passing it around, getting and setting values using RTTI but there we are again, how to create an instance? Yes, specifying the instance and the property by string. Another possibility would be with anonymous methods wrapping the property.

How about some built in type like this?
type
  TProp<T> = reference to property: T;
So I could write something like this:
procedure ShowAndInc(AProp: TProp<NativeInt>);
begin
  ShowMessageFmt('%d', [AProp]);
  AProp := AProp + 1; 
end;

procedure Form1Button1Click(Sender: TObject);
begin
  ShowAndInc(Self.Tag);
end;

What the compiler actually needs to do is something like this (ignoring possible read or write only properties for now):
ShowAndInc(TProp<NativeInt>.Create(
  function: NativeInt
  begin
    Result := Self.Tag;
  end,
  procedure(Value: NativeInt)
  begin
    Self.Tag := Value;
  end));
This is the code of my actual working TProp class and interface:
type
  IProp<T> = interface
    function Invoke: T; overload;
    procedure Invoke(Value: T); overload;
    property Value: T read Invoke write Invoke;
  end;

  TProp<T> = class(TInterfacedObject, IProp<T>)
  private
    FGetter: TFunc<T>;
    FSetter: TProc<T>;
    function Invoke: T; overload;
    procedure Invoke(Value: T); overload;
  public
    constructor Create(Getter: TFunc<T>; Setter: TProc<T>);
    property Value: T read Invoke write Invoke;
  end;

{ TProp<T> }

constructor TProp<T>.Create(Getter: TFunc<T>; Setter: TProc<T>);
begin
  FGetter := Getter;
  FSetter := Setter;
end;

function TProp<T>.Invoke: T;
begin
  Result := FGetter;
end;

procedure TProp<T>.Invoke(Value: T);
begin
  FSetter(Value);
end;
The compiler could do it way better by directly putting the call to the getter and setter into the right places.

So what do you think? Do you want reference to property in one of the next Delphi versions? Any drawbacks I am not seeing right now?

Friday, July 8, 2011

Unattended Delphi installation - how?

Some while ago I was looking for a possibility to setup Delphi with certain customization but without having to enter anything or watching the PC during setup to confirm any dialog.

Unfortunately there is no documentation on the possible and required parameters for the setup. And I have to admit that I am not familiar with InstallAware (which is used since Delphi 2007). But there are some posts which got me on the right track. One of them explains how to get started.

I always install Delphi into the default directory, so no need to specify the TARGETDIR, but if you wish, you can. So we get the following:
Setup.exe /s LANGUAGE=English KEY1=XXXX KEY2=XXXXXX KEY3=XXXXXX KEY4=XXXX
Possible values for LANGUAGE are: English, German, French or Japanese (actually those you had to choose from at the very beginning of the setup until now). KEY1-4 are the 4 pieces of your serial that you normally have to enter in the setup.

So this is pretty much the minimum configuration and you can install Delphi... well and C++ Builder and all the third party tools that ship with RAD Studio and are checked by default. And actually some of them run as external setup that requires user interaction.

Unfortunately I could not find a complete list of all variables you can provide. When you run the setup.exe it extracts another setup.exe and if you open that with a text editor you can find out those variables by looking through the script code. Someone who is familiar with creating setup might explain this better. But at least we know some of the variable names now. I will list some of them I used. All variables are provided in form name=value.

Languages that will be installed (which you can change later by using BDSSetLang.exe): DE, EN, FR and JA (possible values: True or False)

You can change the values for USERNAME and USERCOMPANY which are those specified in windows by default.

To specify which personality to install you set PERSON_DW32 and PERSON_CPPB (both True by default).

Delphi also installs with a handful of 3rd party tools and components. You can specify them by setting (all True by default):
INSTALL_AQTIME
INSTALL_CODESITE
INSTALL_FINALBUILDER
INSTALL_RAVE_REPORTS
INSTALL_SVNCLIENT
If you want to install some of them in silent mode set the following to True:
AQTIME_SILENT
CODESITE_SILENT
FINALBUILDER_SILENT
RAVE_SILENT
SVNCLIENT_SILENT
Other options I use (True or False):
INSTALL_FEATURE_DatabaseDesktop
INSTALL_FEATURE_Indy
INSTALL_FEATURE_IntraWeb
INSTALL_FEATURE_SampleDataFiles
INSTALL_FEATURE_SamplePrograms
INSTALL_HELP
There are lots of other variables to specify much more but I did not touch them so far. If you are interested look for INSTALL_FEATURE_.

So finally my setup.bat looks as follows (when I use it at work I also add the company name):
Setup.exe /s LANGUAGE=English EN=TRUE DE=TRUE KEY1=XXXX KEY2=XXXXXX KEY3=XXXXXX
KEY4=XXXX USERNAME="Stefan Glienke" USERCOMPANY="" PERSON_DW32=TRUE PERSON_CPPB=FALSE
INSTALL_AQTIME=FALSE INSTALL_CODESITE=FALSE INSTALL_FINALBUILDER=FALSE
INSTALL_HELP=FALSE INSTALL_RAVE_REPORTS=FALSE INSTALL_SVNCLIENT=FALSE
INSTALL_FEATURE_DatabaseDesktop=FALSE INSTALL_FEATURE_IntraWeb=FALSE
INSTALL_FEATURE_SampleDataFiles=FALSE INSTALL_FEATURE_SamplePrograms=FALSE
This installs Delphi in english with additional german language files without all the 3rd party tools, without VCL for Web, without samples and without help.

Oh, you can write a logfile with /l="C:\Setup.log" but be aware that it may slow down the installation and produces a logfile of approx 40MB!

If you want to install the help use:
Help_Setup.exe /s LANGUAGE=English PERSON_DW32=TRUE PERSON_CPPB=FALSE
This pretty much makes installing Delphi a one click thing. ;)

Monday, June 13, 2011

The pains of presentation

"It takes one hour of preparation for each minute of presentation time." - Wayne Burgraff  

Did you ever show your data in a virtual treeview? If so, how did you do it? Most likely (at least that's the way I have seen often) you implemented a couple of events for your treeview. Did you have a flat list of objects or did you have some hierarchical structure of data? Most likely this was not the only place you used the treeview to present your data. But you were smart and you did not have the same code for OnInitNode, OnGetText, DoChange or other events all the time, right?

The virtual treeview is one of the most powerful visual components when it comes to presenting data in different ways. And one of the most abused ones when in comes to design and coding principles - at least in my opinion. Some of them are DRY (reimplementing the same events every time), Single responsibility principle and Separation of Concerns (using the treeview as storage and controlling business logic), Dependency inversion principle (gui and business logic are tightly coupled).

So how can we solve these problems? Let's analyze what we got and what we need in common situations. We have a list or hierarchical structure of data and we know what parts of data to show in which column of the tree. So what we need is kind of a presenter. Let me show you what you can do with the DSharp TTreeViewPresenter.

"I am careful with my material and presentation." - Shelley Berman 

The treeview presenter is a component that you can drop on your form and plug the virtual treeview to it. Then you need to set the ItemsSource property of the presenter. You can attach any kind of list that is based on TList<TObject> - due to the lack of covariance in delphi you need a hardcast here. Then you specify the ColumnDefinitions either by using the designtime support or writing some special classes - more on that later.

Ok, we got our treeview, the presenter, a list of customer objects and the column definitions to show firstname and lastname. When we run the application it shows our data in the tree and we can even click on the columns to sort the data.

How does it work? Basically the presenter attaches to the events of the treeview so make sure you don't use those otherwise (well, actually you don't want to since you are using the presenter, don't you?). So this is how the presenter knows about what's going on in the tree. I mentioned writing special classes earlies. The presenter is using the IDataTemplate interface to get information about the items and the structure to display them. For now we just need to know about this function:

function GetText(const Item: TObject; const ColumnIndex: Integer): string;

If you want to write some simple data template and not using the designtime support that's the function you want to override when inheriting from TDataTemplate (the base class for all data templates).

Presenting lists of the same kind of objects is pretty much a no-brainer, isn't it? But what about presenting hierarchical data? Very straight forward as well, let's see.

"The audience only pays attention as long as you know where you are going." - Philip Crosby 

Assuming we want to show folders and files in the tree we need two different data templates one for each class we want to show (actually one for each class that is different, if you have objects inheriting from a base class and you only need data from that base class you only need one template) and register them on the existing data template. Data templates have built-in functionality to recursively look for the best fitting data template. The code for our two templates would look like this:

type
  TFolderTemplate = class(TDataTemplate)
  public
    function GetItem(const Item: TObject; const Index: Integer): TObject; override;
    function GetItemCount(const Item: TObject): Integer; override;
    function GetText(const Item: TObject; const ColumnIndex: Integer): string; override;
    function GetTemplateDataClass: TClass; override;
  end;

  TFileTemplate = class(TDataTemplate)
  public
    function GetText(const Item: TObject; const ColumnIndex: Integer): string; override;
    function GetTemplateDataClass: TClass; override;
  end;

implementation

{ TFolderTemplate }

function TFolderTemplate.GetItem(const Item: TObject;
  const Index: Integer): TObject;
begin
  Result := TFolder(Item).Files[Index];
end;

function TFolderTemplate.GetItemCount(const Item: TObject): Integer;
begin
  Result := TFolder(Item).Files.Count; // containing subfolders in that list as well
end;

function TFolderTemplate.GetTemplateDataClass: TClass;
begin
  Result := TFolder;
end;

function TFolderTemplate.GetText(const Item: TObject;
  const ColumnIndex: Integer): string;
begin
  case ColumnIndex of
    0: Result := TFolder(Item).Name;
  end;
end;

{ TFileTemplate }

function TFileTemplate.GetTemplateDataClass: TClass;
begin
  Result := TFile;
end;

function TFileTemplate.GetText(const Item: TObject;
  const ColumnIndex: Integer): string;
begin
  case ColumnIndex of
    0: Result := TFile(Item).Name;
    1: Result := DateTimeToStr(TFile(Item).ChangeDate);
    2: Result := IntToStr(TFile(Item).Size);
  end;
end;

One thing I am working on is making a generic data template class so you can get rid of the typecasting and defining the GetTemplateDataClass method. You also have to keep in mind that the data template relates to the column definitions because of the column index.

"I am still working on patter and presentation." - Paul Daniels 

When you download the VirtualTreeviewSample from the svn repository you can see more things that are possible with this presenter like data binding, change notification (through TObservableCollection) and using xpath to show xml in the tree in a super easy way. Originally it was designed to be usable in Delphi 7 but in the meanwhile I added a few things that are most likely not compatible (like TList<TObject> which should be easy replaceable). So if anyone likes to use this in an older Delphi version please let me know. I am also refactoring the class to be able to build presenter classes for other controls without having to write everything again from scratch.

As always your feedback is very welcome.

Sunday, June 12, 2011

Drum roll please

Finally, I found a name for my library - let me introduce to you: DSharp

Actually I was pretty surprised that this name was not taken by some programming language or something similar - at least nothing popped up on the first pages of Google results.

The D stands for Delphi of course. And the Sharp is some indicator for its borrowed features from the .Net framework. Also it's short and memorable, don't you think?

I also restructured the svn repository and renamed the units. I am sure everything went fine and you can just update your working repository with the newest revision. Otherwise just get a clean checkout.

Saturday, May 14, 2011

Going beyond dependency injection with MEF for Delphi

You probably read Nicks recent posts about his experiences with the Delphi Spring Framework and especially with their DI Container. To be honest I actually don't know how far they go with it but Nick most likely will enlighten us soon.

As you may know I really like many concepts that we can find in .Net and here is another one: the Managed Extensibility Framework. Its core parts are basically a DI container and one catalog (or more) that contains information about exports and imports. So you can create classes that are not referenced directly by any other part of your application and define an export on them. But that alone would be useless because we actually want to use that class, don't we? So on the other side you can specify an import. Be it for the constructor of another class or its properties.

In the following I will show you how to use this concept in your Delphi application. Because I am very bad in finding examples I took a look around and found this nice example for MEF and I will use very similar examples.

Hello world

So, let's get started. We will create a console application that looks like this:
program MEFSample;

{$APPTYPE CONSOLE}

uses
  MEFSample.Main,
  MEFSample.Message,
  System.ComponentModel.Composition.Catalog,
  System.ComponentModel.Composition.Container,
  SysUtils;

var
  main: TMain;
  catalog: TRttiCatalog;
  container: TCompositionContainer;
begin
  ReportMemoryLeaksOnShutdown := True;
  main := TMain.Create;
  catalog := TRttiCatalog.Create();
  container := TCompositionContainer.Create(catalog);
  try
    try
      container.SatisfyImportsOnce(main);
      main.Run();
    except
      on E: Exception do
        Writeln(E.ClassName, ': ', E.Message);
    end;
  finally
    container.Free();
    catalog.Free();
    main.Free;
  end;
  Readln;
end.


We create the catalog which pulls all the exports and imports from the RTTI and pass it to the composition container which is responsible for resolving those informations when creating new objects or using the SatisfyImportsOnce method on an already existing object like in our example.

Our MEFSample.Main unit looks as follows:
unit MEFSample.Main;

interface

uses
  System.ComponentModel.Composition;

type
  TMain = class
  private
    FMsg: TObject;
  public
    procedure Run;

    [Import('Message')]
    property Msg: TObject read FMsg write FMsg;
  end;

implementation

procedure TMain.Run;
begin
  Writeln(Msg.ToString);
end;

end.

The unit System.ComponentModel.Composition contains all the attributes. If you do not include it, you get the "W1025 Unsupported language feature: 'custom attribute'" compiler warning which means those attributes are not applied.
We specify the Msg property as named import. When calling the SatifyImportOnce Method (which is also used internally when creating objects with the CompositionContainer) it looks for all those imports and tries to find matching exports.

That leads us to the last unit for this first example:
unit MEFSample.Message;

interface

uses
  System.ComponentModel.Composition;

type
  [Export('Message')]
  TSimpleHello = class
  public
    function ToString: string; override;
  end;

implementation

function TSimpleHello.ToString: string;
begin
  Result := 'Hello world!';
end;

initialization
  TSimpleHello.ClassName;

end.

Again, we need to use System.ComponentModel.Composition to make the Export attribute work. We have some simple class that is exported with a name.
One important point: Since this class is referenced nowhere else in our application the compiler will just ignore it. That is why we need to call some method of it in the initialization part of the unit which is called when the application starts. So this makes the compiler include our class.

When we start the application we see the amazing "Hello world".

Using contracts

This worked but actually that is not how we should do this. So let's define a contract called IMessage.
unit MEFSample.Contracts;

interface

uses
  System.ComponentModel.Composition;

type
  [InheritedExport]
  IMessage = interface
    ['{7B32CB2C-F93F-4C59-8A19-89D6F86F36F1}']
    function ToString: string;
  end;

implementation

end.
We use another attribute here which tells the catalog to export all classes, that implement this interface. We also need to specify a guid for that interface. We change our TSimpleHello class:
TSimpleHello = class(TInterfacedObject, IMessage)
and in our main class we change the Msg property:
[Import]
property Msg: IMessage read FMsg write FMsg;

The more the better!

What keeps us from creating another class that implements IMessage? Nothing, so let's do this:

type
  TSimpleHola = class(TInterfacedObject, IMessage)
  public
    function ToString: string; override;
  end;

implementation

function TSimpleHola.ToString: string;
begin
  Result := 'Hola mundo';
end;

initialization
  TSimpleHola.ClassName;

When we run this we get an ECompositionException with message 'There are multiple exports but a single import was requested.' which totally makes sense. So we need to change something:
[ImportMany]
property Msgs: TArray<IMessage> read FMsgs write FMsgs;
and the Run method:
procedure TMain.Run;
var
  m: IMessage;
begin
  for m in FMsgs do
    Writeln(m.ToString);
end;

We start the application and get both messages.

Breaking it down

What if we only want to export and import smaller parts than a whole class? Well then define the export on those parts!

type
  TSimpleHello = class(TInterfacedObject, IMessage)
  private
    FText: string;
  public
    function ToString: string; override;
    [Import('Text')]
    property Text: string read FText write FText;
  end;

  TTextProvider = class
  private
    function GetText: string;
  public
    [Export('Text')]
    property Text: string read GetText;
  end;

implementation

function TSimpleHello.ToString: string;
begin
  Result := FText;
end;

function TTextProvider.GetText: string;
begin
  Result := 'Bonjour tout le monde';
end;

initialization
  TSimpleHello.ClassName;
  TTextProvider.ClassName;

So what is this all about? Different parts of the applications can be created and put together in a declarative way using attributes. With MEF you can create code that is free of unnecessary dependencies - clean code.

The sample and the required units can be downloaded here or directly from the svn. The source is based on some implementation I originally found here.

P.S. I just made the sample also work in Delphi 2010 - this is available in svn.

Monday, May 9, 2011

Lambdas and expression trees in Delphi

Ever wanted to write something like this in Delphi?

for cust in customers.Where(c => c.CustomerId = 'ALFKI') do ...

Actually in Delphi you have to write it like this.

for cust in customers.Where(
  function(c: TCustomer): Boolean
  begin
    Result := c.CustomerId = 'ALFKI';
  end) do ... 

Ugh, lots of code just to declare the anonymous method. Well, we are used to writing more letters in Delphi so that is not really the problem. Another thing is more interesting: expression trees. What can you do with it? Lots of cool stuff. The most interesting for me at least was the ability to create SQL statements with their help. Above for in loop generates adds a where clause to the select statement when using Linq to SQL in .Net. But Delphi does not have such expression trees for anonymous methods... Until now!

Since I have been working with delphi-coll the first time I was wondering if I can actually use them to create something similar to the ADO Entity Framework. The biggest problem was to translate for in loops like above to proper SQL that only fetched the wanted data from the database instead of doing client side filtering. After looking into how .Net does it was obvious to me. I need some kind of support for lambda expressions or more specific the possibility to create some expression tree that I can use to create my SQL statements. But how to inject some kind of expression into a function (in our case the where function) without writing an anonymous function or at least without writing a super complicated one that only works when using some SQL queryable?

When I googled "Delphi lambda linq" the second hit brought me to the first idea. Basically a combination of records with operator overloading containing interfaces. You can do some funny stuff with them but there is some limitation. As soon as you want to access a property of some object you are lost (like we want to do in our example). So how to make a property or function call without actually calling it. I know that sounds weird but what I want to achieve is to record the complete expression. This brings us to invokable custom variant types. I am not going to explain how they work but if you want to know more you can read some articles about it here and there.

The important thing is: We can have calls to a property or method like in our example (c.CustomerId) without actually calling and getting a return value. Well we get a return value but it will be a variant which encapsulates the expression object for this property or method. So we have the information now but can invoke it later. Let's look at our anonymous method we use for filtering our customer list. It gets one parameter of the type TCustomer and returns a boolean. So how to write our expression now?

for cust in customers.Where(
  TLambda.From<TCustomer, Boolean>(Arg1.Customer = 'ALFKI')) do ...

Oh wow, whats this TLambda and that Arg1?! TLambda is a record with some static methods like From which supports all kinds of TFunc defined in SysUtils (well not all so far but they will get added). This methods creates some anonymous method and returns it.
Arg1 is a function (there are 3 more) to create an expression that takes care of the first parameter of the anonymous method. So in our case the TCustomer object we pass in when we call the method.

So what about that expression tree? We actually can get that out of the method reference. Wait what? Yes, as we know they are just objects hidden behind some interface. Which means: you can get RTTI for them. And getting RTTI means you can extract information and even modify them. TLambda has 2 methods to get and set the expression that is executed inside the method when its called.

So now we can inspect and iterate our expression tree and generate where clauses and other funny things. So if you want to access a parameter of the method just use the ArgX functions. If you want to use variable capturing put them into Arg function so you can use the current value when actually executing the method (just supported for objects so far).
One thing you have to remember is: You cannot use normal functions inside that expression because that results in direct execution. But you can write wrappers for them as shown in one of the samples.

All in all this is a very early prototype but it works pretty well so far in a single threaded application.

To make this work in your program just use System.Lambda (and System.Expressions when you want to create your own expression tree).

You can also see how it works in the 2 new demos (Sample6 and Sample7). For the second sample you need delphi-coll to make it work.

Sunday, May 8, 2011

New features for data bindings

In the last week bindings got a lot new features:

Property path:
That means if you want to bind for example MainForm.Font.Size to your control you easily specify it by setting the MainForm as Source and Font.Size as SourcePropertyName.
You could do that before already but you had to bind to MainForm.Font as Source and Size as SourcePropertyName. But that was not possible in the IDE because of the limitation of the property editor for the source property. It is on the todo list to support nested object properties for the source property in the IDE also.

Collections:
Bindings now support collections. More exactly, descendants of TEnumerable<TObject> that implement INotifyCollectionChanged. There is a new base class called TObservableCollection<T> which inherits from TObjectList<T>. I added one control so far that supports this: TListBox.
There is a new sample that shows how to display a list of data objects in the listbox and how to bind other controls to edit the selected item.
Since that feature is still under development you might notice some problems with it especially not updating listbox when selected item has been edited. Also when creating and freeing objects in the FormCreate and FormDestroy that are referenced by design time defined bindings you might experience some problems. Make sure you handle those objects in the constructor (before inherited) and destructor (after inherited) for the bindings to recognize them correctly.

Data templates:
This piece came from another project (which I will let you know about shortly) but made perfect sense for the collection support. When you add a list of objects to some control. How should the control know what data to display? This is what data templates are for. You specify what class the template is for and what data is displayed. If you look at the code you might recognize where they originally came from.

Tuesday, May 3, 2011

IDE support for data bindings

Some of the coolest techniques lose their attraction when they are not easy to use or if you have to write to much code every time you want to use them. So often there are IDE plugins, wizards or tools of all kinds to make programmers life easier.

I was thinking the same about the data bindings. Sure, every binding is just one line of code at least and adding that controls unit to the uses. But wouldn't it be much more awesome and true RAD if you could set up your bindings just via object inspector? Good news, you can!

When I started thinking about design time support I was remembering that I had seen some magically appearing properties in the object inspector when I put some controls on a TFlowPanel. Also I remembered something about TGlassFrame when it was introduced in Delphi 2007. So I started looking for some articles and I found them, explaining how they managed to introduce that new property without breaking existing classes.
I will not go into detail here but if you interested I recommend to read Hallvards and Allens posts. So the important thing about the design ide is: you can add your own properties for the object inspector you can specify where the values come from (and of course you can remove properties). TEdit for example did not have any additional field or property (except the subclassed controls from the extra unit but that was runtime only).

So where do we take the value from that we can edit in the OI? There is a component now called TBindingGroup that you can add to your form that serves as a container to all the bindings that are created. There is no additional property in the OI until you place one on your form. From now on you can specify the source object and property, the binding mode and the update triggers for the components that are specified to support bindings. Everything is saved inside the binding group and also saved in the dfm file. And the binding group serves one more purpose. If you place it on your form you don't have to add those extra unit to your uses clause since it does so automatically. This is also done by registering your own TSelectionEditor descendants in the design time package.

For a detailed description about adding custom properties to your classes in the IDE I suggest to read this nice article.

So this is what you see when you have placed the binding group component on your form.



Another new feature is that bindings now use a default value converter if the source and target properties have different types if not specified otherwise. That default converter does not convert many data types yet but for the most common uses like showing date/time values in labels or setting numeric values in an edit it is enough.




The full library is avaible here. Just compile and install the package, set the library path and you are ready to use data bindings in your projects.

Saturday, April 30, 2011

Data Bindings

I just published a post about my Delphi data binding implementation on Delphi-Praxis.

Since it is german here is the translation:

Those who already worked with .Net most likely know and like them: data bindings
You can bind almost everything. Like showing collections of objects in tree-, list- or gridviews or editing properties of objects in text-, check- or comboboxes. You can even change the visibitiy or the appearance of controls with them.

You can read about how it works exactly on the MSDN.

So what? In Delphi we have dataset, datasource and those db controls to do this!
True, but there is just one catch: you cannot just add a foo object to them. True, there is TSnapObjectDataset or special controls to do that. The problem is that you have to use those special controls or components and you have to inherit your bindable objects from some base class.

So I took a closer look at how .Net does it and implemented it in Delphi with the following goals in mind:
  • standard out of the box components have to be supported (i.e. TEdit)
  • little implementation necessary for bindable objects
  • little source code to actually bind objects

Ok, lets start. What do we need?

A binding always requires a source and a target (both objects) and the names of the properties that are bound.
For our first example we create some simple class that got 2 properties:

type
  TSettings = class
  private
    FCaption: string;
    FColor: TColor;
    procedure SetCaption(const Value: string);
    procedure SetColor(const Value: TColor);
  public
    property Caption: string read FCaption write SetCaption;
    property Color: TColor read FColor write SetColor;
  end;

implementation

procedure TSettings.SetCaption(const Value: string);
begin
  FCaption := Value;
end;

procedure TSettings.SetColor(const Value: TColor);
begin
  FColor := Value;
end;

We already have those explicit setter methods - we will need them later. For a first example we could get rid of them but since the auto completion created them we just let them where they are.

So, what are we doing with out TSettings object? We create 2 bindings to set the caption and the color of our MainForm.

procedure TMainForm.FormCreate(Sender: TObject);
begin
  FSettings := TSettings.Create;
  FSettings.Caption := 'Binding demo';
  FSettings.Color := clGray;
  TBinding.Create(FSettings, 'Caption', MainForm, 'Caption');
  TBinding.Create(FSettings, 'Color', MainForm, 'Color');
end;

It only requires using the System.Bindings unit. Also we do not need to take care about freeing the objects as long as one of the bound objects if inherited from TComponent (in our case that is the MainForm).

Lets start the application and see what happens. Caption and color of the MainForm are set according to the values in our TSettings object. Awesome, no?
Well, setting those values would have done that too... Sure, but that's not the end of the story!

Lets put a button on our form and set the properties of our settings object there.

procedure TMainForm.Button1Click(Sender: TObject);
begin
  FSettings.Caption := 'Current time: ' + DateTimeToStr(Now);
end;

That is not doing anything for now but we are not done yet. Let's go back to out TSettings class and modify it.
We inherit from another class that already implements the INotifyPropertyChanged interface. Nicely taken from .Net of course. Ah, now we need the setter methods for the properties.

So that is how the modified class looks now:

type
  TSettings = class(TPropertyChangedBase)
  private
    FCaption: string;
    FColor: TColor;
    procedure SetCaption(const Value: string);
    procedure SetColor(const Value: TColor);
  public
    property Caption: string read FCaption write SetCaption;
    property Color: TColor read FColor write SetColor;
  end;

implementation

procedure TSettings.SetCaption(const Value: string);
begin
  FCaption := Value;
  DoPropertyChanged('Caption');
end;

procedure TSettings.SetColor(const Value: TColor);
begin
  FColor := Value;
  DoPropertyChanged('Color');
end;

Now if we click the button the caption of the MainForm changes. Nice, but still not rocking that much, isn't it?

Well, ok. Let's throw some edit on our form and bind that to the caption of the MainForm.

TBinding.Create(FSettings, 'Caption', Edit3, 'Text');

Wow, now the caption is displayed in the edit but it's doing nothing when I type.
Correct, we are missing something. The unit System.Bindings.Controls has to be used as the last unit in the interface section (or to be more precisely after the units with the controls we wanna bind to).
This unit contains subclasses to some standard VCL Controls with the same name that implement the INotifyPropertyChanged interface. Using this unit after the other VCL units makes those classes the ones that are used when the controls are created. That means you don't have to place special controls on your form to use data binding. Just the normal out of the box ones.

Let's start the application again and type something into our edit. Awesome, the caption of the form changes!

To make it clear:
  • no special controls needed (only the subclassing of the controls that you want to be bindable to)
  • no special events needed
  • can use TObject descendants for read-once sources (only implementing of the interface if necessary to notify on changes)
  • little source code to actually bind objects, components and controls

What is missing so far is binding collections to other components but this is already in the works. So you will be able to bind your lists and collections to controls like TListBox or even a TVirtualStringTree.

Your feedback is welcome as always.

The sample and all source code can be downloaded here.

Sunday, April 17, 2011

Yield return and Delphi

Well, some may know that Sergey Antonov already came up with some implementation on the yield functionality for Delphi in 2007. It was pretty impressive but for my taste it involved to much asm stuff and it was before Delphi had generics.

So what if we could do something like this?

for i in Power(2, 10) do
begin
  Writeln(i);
end;

Well, you can! All you need is define the function as follows:

function Power(ANumber, AExponent: Integer): IEnumerable<Integer>;
begin
  Result := TDelegateEnumerable<Integer>.Create(
    procedure
    var
      i, k: Integer;
      Result: Yield<Integer>;
    begin
      k := 1;
      for i := 1 to AExponent do
      begin
        k := k * ANumber;
        Result := k;
      end;
    end);
end;

Looks pretty much simple and straight forward, eh?

So what happens there? Well basically it creates some TEnumerable<T> descendant which takes a TProc as parameter and executes it when GetEnumerator is called. Well but thats only half the truth. The real magic happens when you assign a value to that Yield<Integer> variable. And that's basically a record with some implicit operator overload which makes the worker thread or fiber (for now you can only set that with a compiler switch in the Collections.Yield.pas) continue and make the Enumerator do his MoveNext and provide the value for the GetCurrent.

I also implemented support for Alex Ciobanu's awesome collection library (you can also set that up with a compiler switch in the Collections.Yield.pas). Then you can do something funny like this (provided that you set the result type of your function to IEnexCollection<T>):

for i in Power(2, 10).Reversed do
begin
  Writeln(i);
end;

Ok, you might say, I can do all that with getting my values and putting them into some list and I can easily go through it with any loop I want. True, but then you will either have to wait until your calculation and processing is done and the list is generated. And also you have to carry around the list and the elements in it. What if you just want to set up some parameters and calculate the result later? Well with that implementation you can since the enumeration procedure is just called when GetEnumerator is called.

So, pretty cool, no? What do you think?

P.S.: The full source code is available on google code as always.

Thursday, April 14, 2011

Delphi sorcery project on Google Code

Ok, I just created a project on google code and added the first files.

It's a first version of a data binding class which includes a multicast event implementation and a class to add lifetime management to objects that are not inherited from TComponent.

I also added a small sample to show how easy it is to bind properties to controls with just one line!

Some people might call subclassing the VCL controls and adding that unit as the last in the interface uses a hack... I call it using the force for the greater good. 8)

Wednesday, April 13, 2011

Initialization

Well ok, I finally made my own blog...

I will post here about Delphi related topics and programming stuff in gereral. Mostly about things that my coworker refers to as "magic" or "voodoo" hence the name of the blog. :)