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.
Page files should reside in the application's Resources directory. I will usually put each main pane in its own page, such as main_page.js
, log_in_page.js
, and so on. If there are a lot of accessory panes or they are complex, you may want to split them into multiple SC.Page
containers across multiple files too.
18.118.186.143