The MVC design pattern in Page Designer – Part 1

Today, I’d like to talk about the “Model, View, Controller”-Design pattern and how all this is reflected in APEX Page Designer.

Picture source: xkcd Flowchart comic
Picture source: xkcd Flowchart comic

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.

Disclaimer: I’m not part of the APEX development team and there’s a lot of undocumented stuff. Most of my knowledge I acquired by trial and error and by looking at the APEX javascript source code.
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?

In todays’ world where more and more logic is being executed in the browser, you as a javascript developer are faced with a difficult task:

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.

What fascinates me most, is that Page Designer mainly consists of a single APEX page (4500) in the Application Builder application. Still it offer such complex javascript front-end functionalities, that it makes perfectly sense to follow a design pattern.

So let’s start with a schematic overview of MVC.
In our case this is all on the client (=browser):

MVC-architectureImage 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.
  • The view is made with HTML, CSS, Javascript (and templates)
    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
javascript stack that makes up the Page Designer front-end:

MVC-stack in Page Designer

In part 2 of the series (appearing in May) I will go into technical details of the Page Designer model (exposed through the “Properties Editor” pe javascript Object) and then work our way up to the view and controller layer.

In the mean time, if you want to learn more about javascript design patterns in general, I really encourage you to take a look at the free online book by Addy Osmani called Learning JavaScript Design Patterns.

So stay tuned or -if you can’t wait that long- come see my presentation at APEX Connect 2016  😉


Leave a Reply

Your email address will not be published. Required fields are marked *