Since an application may have several different preconfigured panes and pages (that is, subclasses of SC.Pane), we need a means to organize them all. This is the purpose of the SC.Page object. But don't let the name confuse you. SC.Page is not a type of SC.View and has nothing to do with rendering the visual page. It is simply a storage object used to hold preconfigured but un-instantiated panes and views.

Using an SC.Page container gives your application an anchor point for looking up a particular view tree and retrieving it for use. This is convenient, but the real work of the page container is that it will only instantiate objects when they are accessed the first time, allowing you to avoid creating all your panes at launch or defining classes that would be wasted with only one instance. I realize that this idea may be a bit abstract right now, so let's look at an example.

Here's the skeleton of a file that will represent the login page for an application. It contains the main page (mainPane) and a panel for creating a new account (createAccountPane). You can imagine that these two panes would eventually contain several predefined views, but for now I've left them empty.

So, why put these inside an SC.Page file? Well as I mentioned previously, MyApp.logInPage is a singleton, which allows you to easily access the page anywhere within the application. What we will encounter later is that we will likely have a login state that will work in sync with this pane, appending it as the state is entered.

For example:

// entering log in state
MyApp.logInPage.get('mainPane').append();

Likewise, if the user clicks on a Create Account button, we would want to handle that by appending the pane returned by MyApp.logInPage.get('createAccountPane').

The next point I made about how using SC.Page is better than a singleton or a class, is a bit more difficult to describe. So, let's look at what happens when I play around with logInPage in the browser's console:

Let me walk you through the previous example. First, I accessed the mainPane property using dot notation, which is against key-value coding principles, but I did so to prove a point. When I used dot notation the first time, we see that MyApp.logInPage.mainPane is an SC.MainPane class. This means that the pane has not been instantiated and we haven't paid the setup cost required to connect bindings and observers. In fact, if we never use this pane, it will never get instantiated, saving on processing and memory. This is better than using a singleton for the mainPane, which would have been created when the file would have been parsed, hampering the performance at launch.

Next, I accessed the mainPane property properly using get and we see that SC.Page instantiated the object for me. Finally, I accessed the property again using dot notation just to check and we see that something interesting has happened. The class has now been replaced by the instance. This is a subtle feature, but because there is only ever one mainPane, we don't need to keep the class around and so SC.Page replaces it, freeing up a bit of memory.