CODEWITHSUNDEEP
delphimodel-view-controlleroopwebbrowser-control
Stijn Sanders
Stijn Sanders

Reputation: 36850

What does an MVC Delphi with WebBroser and HTML application look like?

I was confused when I first read Christer Fahlgren's comment on an answer on this question, where he states you would benifit from using 'MVC style design' when starting an application that uses both Delphi and a WebBrowser component on a form, and HTML with CSS and JavaScript to create a fancy mix of flexible UI and dynamically updating visuals.

I've been doing this in Delphi some time before I heard about Ajax, and a lot before I was hearing things about 'MVC'.

Perhaps this would be a good occasion to ask for help on the question: What does code look like that uses MVC design.

I've always understood paradigms much better by reading working source-code, then lengths of literature on some technical subject. What would a prototype textbook-example Delphi-WebBrowser-HTML-DOM-modifying application designed by the MVC pattern look like?

Upvotes: 4

Views: 1277

Answers (3)

Christer Fahlgren
Christer Fahlgren

Reputation: 2474

I think Smasher explained the basics well. Why I was thinking MVC is a good style is that the Delphi part would be the model and the controller, the HTML+CSS+Javascript defines a view by calling in to a late-bound COM component defined in the Delphi app. Here is a nice article: How to call Delphi code from scripts running in a TWebBrowser explaining how to make calls from Javascript in to Delphi.

Upvotes: 0

jpfollenius
jpfollenius

Reputation: 16620

A very simple demo application demonstrating the general principle:

TModel = class
  property ValueList : TList <Double> read ... write ...;
end;

You could then have multiple views that visualize the model, i.e. one view that displays the values in a table and one that displays the values in a diagram:

IView = interface ['{0D57624C-CDDE-458B-A36C-436AE465B477}']
public
  procedure Update;
end;

TTableView = class (TInterfacedObject, IView)
private
  FModel : TModel;
  FController : TController;
public
  procedure Update;
end;

TDiagramView = class (TInterfacedObject, IView)
private
  FModel : TModel;
  FController : TController;
public
  procedure Update;
end;

The views do only read data from the model. All interaction with the GUI is delegated to the controller class (which uses the Observer design pattern by the way):

TController = class
private
  FModel : TModel;
  FViewList : TList <IView>;
private
  procedure UpdateViews;
public
  procedure AddDataValue (Value : Double);
end;

The implementation of AddDataValue could look something like:

procedure TController.AddDataValue (Value : Double);
begin
  FModel.ValueList.Add (Value);
  UpdateViews;
end;

procedure TController.UpdateViews;
var
  View : IView;
begin
  for View in FViewList do
    View.Update;
end;

This way you achieve multiple things:

  • You can easily use multiple views (either allow the user to switch beetween views, or show them simultaneously)
  • All data is in the model and completely separated from the presentation. Change the representation, change nothing in the model.
  • To implement persistance you only have to save the model.
  • You could use the controller to execute all necessary checks. (Instead of implementing this for each view)

For a complete list of advantages, the web is full of discussion of the MVC pattern and its alternatives.

In Delphi applications you may find that the controller is kind of overhead because of the event-based programming style in Delphi. What I often do is to only split my application into model and view.

Upvotes: 2

Fabricio Araujo
Fabricio Araujo

Reputation: 3820

MVC stands for "Model-View-Controller". So, an application that uses MVC makes it's interfaces in the following way:

  • have classes that encapsulate business rules on the business layer (which is the "Model" on MVC)

  • a form (on a desktop application) or a html(jsp, asp.net, coldfusion, etc) page, which is the visual presentation of functionality for the user. (it's the "View")

  • a class (or a method, depends of the complexity) that modifies the "View", making it act on the desired behavior. (the "Controller")

So the controller is tied on the model and view. The view is not tied to a specific controller (so it can reused on another part), nor the Model.

It's the controller that makes things happen. It interects with the Model classes and controls the view's behavior.

This is what I understand for MVC.

Upvotes: 0

Related Questions