WiseMVC makes it to GitHub

! Warning: this post hasn't been updated in over three years and so may contain out of date information.

wisemvcLast week, I released a preview of WiseMVC, with the aim of getting feedback on the idea. I was really pleased to get some seriously high quality feedback from Frédéric Saunier. He suggested lots of improvements and asked me some thought-provoking questions on why I was doing it. As a result, I have reworked the code to take many of his ideas into account.

Controller class set
PureMVC has Facade, which is the application’s entry point into the MVC and Controller, which fulfils the controller aspects of the MVC pattern. WiseMVC replaces these two with a single Controller class, which is both the application’s entry point and the MVC controller. In my original design, the Controller had to be exposed to the Model and Proxies, which broke the MVC pattern. The reason for doing this was a pragmatic one. PureMVC uses a globally accessible singleton Controller. So whilst its guidelines might specify which aspects of the pattern ought to access it, there was nothing to stop folk writing code that ignored these guidelines. In order to be compatible with such projects, I made Controller fully accessible within WiseMVC. Taking advice from Frédéric, I have reworked this idea. Now Controller is part of an inheritance chain:

NotificationSender <- ObserverController <- Controller

NotificationSender is a basic class that – as its name suggests – supports sending notifications. Controller is exposed to Model as an instance of NotificationSender. Through the beauty of inheritance, this means that Model and Proxies are only able to send notifications. They cannot access any of Controller’s other features. However, there are now two “pragmatic fallback modes”, which enables NotificationSender to expose itself to Model as either an instance of ObserverController or the full-blown Controller. In turn this greater exposure of Controller’s functionality is passed on to the Proxies.

ObserverController builds upon NotificationSender's functionality by providing access to methods for adding and removing Observers. Controller is exposed to View as an instance of this class, giving it and the Mediators access to functionality that is found in PureMVC’s View class, but which I have moved to the Controller inheritance chain in WiseMVC. The fallback mode that gives Model access to all of Controller's functionality works for View too.

At this stage of development, I’ve decided that now would be a good time to make WiseMVC available to others via github. At this stage it is still beta code though:

  • It’s still untested on a good sized project
  • It’s subject to major change without warning
  • It’s still not properly documented
  • The licensing and attribution to PureMVC is still work in progress
  • The unit tests still test only PureMVC-style functionality and not the new WiseMVC functionality

Despite this, I feel it better to give everyone access now, rather than trying to be perfectionist about it. The reason for this is simple: Frédéric or the like might still have some great ideas on how to improve it up their sleeves and so there’s no point in me in me putting finishing touches to something that might yet change again.

So as before, please do not be shy over your thoughts on the WiseMVC project. Also please be patient with me if you are a git expert and I’ve done something wrong on github, as I’m learning git through this project. If you need to shout at me about something, send it to david at this blog’s base domain.

3 thoughts on “WiseMVC makes it to GitHub

  1. Congrats David, and even more as I read on Twitter that you’ve lost parts of you’ve work during the process needing you to redo some work. Thanks a lot for the remarks on my help, but my part was the easiest has I only had play the role of the guy who criticized the work you did, you made it and you made it well by your own!

    I only had a quick look into WiseMVC sources on Github, and I saw that you also thought to use ObserverContoller in Mediator not just in View (I forgot to mention that I had saw this reference to Controller in Mediator last time).

    When I only read imports from each of your classes I immediatly recognize the PureMVC scheme, names you give to your framework classes are well thought. I mean that developer can immediatly understand that Proxy only has right to send notification never to receive ones as it uses NotificationSender not ControllerObserver, while Mediator has both.

    As I previously said, I’m curious to test it in a multicore app. But as it looks like a perfect FrontController pattern implementation I don’t think that any bad surprise will interrupt the experience.

    Later, I will try to compare it to the current PureMVC implementation and try to better understand why Cliff decided to use Facade instead of only the FrontController.

  2. >> and try to better understand why Cliff decided to use Facade instead of only the FrontController

    @ Tekool why not ask him, I have no doubt that he will give a very good answer 😉

    @Dave well done sir another darn framework to checkout! (lol)

  3. Well hours after putting it on github, it occurred to me that in my rush to be clever, I forgot some basic rules of inheritance and polymorphism. Proxy requires an instance of NotificationSender. It is passed as instance of Controller and in my naivety, I assumed that as Proxy sees it as a NotificationSender, it would only be able to access the controller as if it were an instance of NotificationSender. This is of course utter nonsense: cast it back to Controller and all the features are accessible again.

    I am therefore reworking it again. This time Controller, NotificationSender and ObserverController are separate classes in the same package, so they can use internal to share data between them. Hopefully this will appear on github this evening.

Comments are closed.