Today, I’d like to talk about the “Model, View, Controller”-Design pattern and how all this is reflected in APEX Page Designer.
This is the first part of a series of blog posts where I’ll share my knowledge on Page Designer internals I gained while working on the Xplug browser add-on.
I apologize in advance for any errors my blog posts may contain.
Perhaps some good advice first: don’t take anything for granted and always double-check yourself.
That being said, I’m a speaker at APEX Connect 2016 and the MVC-topic is part of a presentation I’m currently preparing for the Web Technologies track. It’s called “Lernen vom Page Designer – Auf den Spuren von Jules Vernes” .
Please bare with me. It’s going to be a rather long and somewhat theoretical blog post. I’ll do my very best to keep it interesting.
You might ask yourself what a software design pattern is and what all this fuzz on MVC is about in the first place?
You need to implement a complex application which is both user- friendly and efficient in terms of resource usage and at the same time keep your source code maintainable. You are probably also not working allone on this. You have a bunch of peer developers that implement other parts of that exact same application. Avoiding spaghetti code at all times is a top-priority.
Here is where a design pattern can help you. Wikipedia says:
It is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.
In our case MVC helps you write better organized and therefore more maintainable code. It describes the way how you can structure your source code in separate “layers” and how these communicate with eachother.
So let’s start with a schematic overview of MVC.
In our case this is all on the client (=browser):
Image is courtesy of the Google Chrome Developer blog
Source: some of the more generic information is taken from the Google Chrome Developer blog).
- The model is where Page Designer data objects are stored.
Once Page Designer has loaded, all communication with the database takes place via AJAX calls. This is for example the case when a page definition is loaded into page designer.
It’s important to know that all data that is exchanged is in JSON format and its representation is stored in the model.
- The model itself doesn’t know anything about views and controllers.
That’s right, there should be no direct communication nor method/function-calls from the model layer to the other layers.
By following this rule we get an increased modularity and avoid direct dependencies between layers.
- When a model changes, typically it will notify its observers that a change has occured.
So far I haven’t talked about the Observer pattern. I’ll go into the details in part 2 of the series.
In a nutshell: An object (the subject) maintains a list of objects that depend on it (observers). If there’s a change to the subject it will notify all its observers so that these can react accordingly. Will be further addressed in part 2 of the series.
For a Page Designer example, you might want to take a peek at <install folder>/apex/images/apex_ui/js/f4000_p4500.dump.js
- A view is what’s presented to the users and how users interact with the app.
In our case the APEX 5.0 widgets and the custom-made widgets for Page Designer play an important role.
The widgets use jQuery UI under the hood.
- The controller is the decision maker and the glue between the model and view.
This is the layer where the page designer “business logic” resides.
- The controller updates the view when the model changes.
- The controller adds event listeners to the view and updates the model when the user manipulates the view.
In the below slide, I try to map the MVC-architecture to the
So stay tuned or -if you can’t wait that long- come see my presentation at APEX Connect 2016 😉