Here I have a concrete problem, wich is a possibility in cacao but (as far as I can see) is not explained: work with documents and tool panels.

How can I have a document, wich contains a window and have tools in diferent panels, of course, wired with de document (or documents open that may be many).

BTW, this is one of my cacao’s guru bookmarks since a month ago and really apreciated your help a lot.

All the GUI is designed in a different code file (in vs2008 anyway) and if you stick to putting your event handlers in the partial class that vs gives to you then i think that that is separation enough.

OK its not oop mvc of course – but who cares, what i want is a separation of the form design and the event handlers – all i need to do is define a model to talk to and i’m away.

All that said I have built .Net apps that are like Cocoa apps using MVC. As you can see by the following example it’s not nearly as straight forward as developing in Cocoa, but it does mimic the Cocoa app above. What I really find interesting is both frameworks provide a very similar set of functionality, but the focus on how applications should be built is completely different.

using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Text; using System.Windows.Forms;

namespace MVCSharp { public class FormInput : Form {

    public Controller controller = null;
    private TextBox textBox = new TextBox();
    private Button updateButton = new Button();

    public FormInput() {
        this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
        this.Text = "FormInput";
        this.Padding = new Padding(10);
    }

    public void Initialize() {
        controller.ClientConnected++;

        textBox.Multiline = true;
        textBox.Dock = DockStyle.Fill;
        this.Controls.Add(textBox);

        updateButton.Dock = DockStyle.Bottom;
        updateButton.Click += new EventHandler(controller.updateText);
        updateButton.Text = "Update Text";
        this.Controls.Add(updateButton);

        textBox.DataBindings.Add(new Binding("Text", controller, "InputText"));
    }

    protected override void OnClosed(EventArgs e) {
        base.OnClosed(e);
        controller.ClientConnected--;
    }
}

public class FormOutput : Form {

    public Controller controller = null;
    private TextBox textBoxEcho = new TextBox();

    public FormOutput() {
        this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
        this.Text = "FormOutput";
        this.Padding = new Padding(10);
    }

    public void Initialize() {
        controller.ClientConnected++;

        textBoxEcho.Multiline = true;
        textBoxEcho.ReadOnly = true;
        textBoxEcho.Dock = DockStyle.Fill;
        this.Controls.Add(textBoxEcho);

        textBoxEcho.DataBindings.Add(new Binding("Text", controller, "OutputText"));
    }

    protected override void OnClosed(EventArgs e) {
        base.OnClosed(e);
        controller.ClientConnected--;
    }
}

public class Model {
    public string inputText;
    public string outputText;
}

public class Controller {

    private Model _model = new Model();
    public int ClientConnected = 0;

    public void Initialize() {
        _model.inputText = "";
        _model.outputText = "";
    }

    public void updateText(object o, EventArgs e) {
        _model.outputText = _model.inputText;
        OnOutputTextChanged(new EventArgs());
    }

    public string InputText {
        get { return _model.inputText; }
        set { _model.inputText = value; }
    }

    public string OutputText {
        get { return _model.outputText; }
        set { _model.outputText = value; }
    }
    public event System.EventHandler OutputTextChanged;
    protected virtual void OnOutputTextChanged(System.EventArgs e) {
        if (null != OutputTextChanged) {
            OutputTextChanged(this, e);
        }
    }
}

static class Program {
    /// 
    /// The main entry point for the application.
    /// 
    [STAThread]
    static void Main() {

        Controller controller = new Controller();
        controller.Initialize();

        FormOutput viewOutput = new FormOutput();
        viewOutput.controller = controller;
        viewOutput.Initialize();
        viewOutput.Show();

        FormInput viewInput = new FormInput();
        viewInput.controller = controller;
        viewInput.Initialize();
        viewInput.Show();

        while (controller.ClientConnected > 0) {
            Application.DoEvents();
        }

        Application.Exit();
    }
}

}

I would even say that Interface Builder + properly Cocoa MVC’d code gives you easier and greater UI malleability than HTML + well-written Javascript.

(Why am I harping on about UI malleability? Because the UI is your app’s most important aspect, and thus the UI has to be reiterated many times and evolve far before you get it right)

What is known as “True MVC” is the approach where the model and view and as dumb as can be, and the controller is the mediator through which all business logic processing happens. Cocoa follows close to this “True MVC” approach, however, Cocoa adds a little bit more flexibility through the delegation mentioned in this post, as well as the key value observing system, which makes it easy to link together complex views and do notifications of a change in data application wide.

It’s perfectly fine to remain unconvinced that it makes you a better programmer, but you won’t be able to do Cocoa development unless you do drink it in. ;-)

You have to decide whether or not you want to be a Cocoa developer. If the answer is yes, then buy the Hillegasse book and get going. No shortcuts–just diligence.

Best regards,

-Matt

Are there any short-cuts to enlightenment? I’m unconvinced that MVC makes your code better.

W

I agree with you. I think I will also provide the why of MVC. Rather than try posting it here in the comments, though, I think I’ll do a follow up post. Thanks for the insight. It’s appreciated.

-Matt

Your article explains exactly why Cocoa dev is so enjoyable. It’s not so much about learning how to do this and how to do that; it’s about understanding the paradigms. I constantly marvel at them; there’s a kind of elegance about the Cocoa way of doing things that makes coding a pleasure.

MVC is essentially a data-management pattern – the view is a pool of data pulled from the model and manipulated by the controller. The view is so-called because it’s a window onto the content of the model.

In more complicated scenarios you have multiple view + controller pairs, each targeted at a particular category or subset of data in the model and servicing a particular aspect of the display. Typically in these scenarios the view + controller is merged into a single object that performs both duties. Let’s call it a view-controller.

Classically the MVC is always presented in relation to user-interfaces but the UI is never shown in the diagram and this leads people into assuming the view is the UI. Writing an MVC-based application is relatively trivial once you realise the UI is not the view.

In .NET terms, the data displayed on the form is bound to the appropriate properties of the appropriate view-controller and the event processing code-behinds call the methods exposed by the same view-controller. To provide easy access to the view-controller the coder can instantiate them in the application object’s constructor at start-up and expose them as properties. In this way the forms can always bind / call the required view-controller.

The majority of coders haven’t been exposed to the ‘full on’ object-oriented coding experience of using a language like Smalltalk, Objective-C or Ruby. They don’t ‘think in objects’ so MVC seems like witchcraft.

In this article you talk about the MVC pattern, but you never explain why it is better than just placing code under buttons in the views (forms for Windows users).

As you state in the article, the .NET UI practically begs you not to use the MVC pattern, and so to some Windows developers who have now started to look at the Mac, the MVC pattern might actually be a foreign concept entirely!

So what is the answer to “Why is MVC important?”

It is because it allows the views to vary while giving them a single point of reference to code that provides (and maybe updates) their data.

Say for instance that you have an application that provides views that allow the data to be edited, but has security built in so that certain users can only view the data.

In the Windows world where the developer hasn’t used MVC, you would have to set the visible property of the Save buttons to false. Easy… but limiting. What if the controls in the views could be arranged so that they provide for better legibility to the “read only” user? What if a lot of controls in the forms need to be hidden because they are only relevant to users who can edit the data?

Without MVC, you are stuck writing a lot of code to move/resize or hide controls on your forms. Not fun!

In the MVC compliant application you can replace your views entirely with views that are designed with legibility in mind, while simply reusing the controller to get the data from your data source.

I hope this helps any other Windows developers who have started to look at the Mac as a development platform.

Best, Steven

I should point out though that my experience of C# is not that great, and I’ve recently been using Cocoa# anyway (and writing Cocoa-style model and controller objects as a result). Google brings up some good M-V-VM results after a search for “ViewModel”, including some which compare it with traditional SmallTalk MVC.

Cheers, Graham.