Dear Mr. Palindrome,

Please don't be embarrassed, as this was difficult for me when starting SproutCore as well.

I'd like to tackle this problem by discussing two broad concepts, so please bear with me.

The first is that we must differentiate between instances and classes. I presume that in the JavaScript that defines your custom views, you are using the extend or design methods to describe the UI.

For example, your code probably looks something like:
MyApp.CustomView = SC.View.extend({
  childViews: 'countView labelView'.w(),
  layout: { width: 300 }

Now you might be thinking: "Instantiating and managing all of those views sounds like a pain in the ass." And you would be right if you had to do it yourself.

Fortunately, there exists the elegant (if strangely named) SC.Page class.

In a nutshell, an instance of SC.Page will dynamically instantiate views as they are needed, deferring the CPU and memory hit of instantiation until the very last moment possible. Here's how it does it:
1. You call get() on your page.
2. SC.Page overrides the get() method.
3. The Page version of get() retrieves the given property.
4. It checks to see if the property is an instance or a class.
5. If it is an instance, it returns the stored value. Otherwise…
6. It creates an instance of that class and replaces its own property with the instance.

The next time you call get(), it will return the same instance that it created the first time, so you're always dealing with the same object. Pretty neat, huh?

Now, the next concept to understand: SC.ContainerView.

As you've already discovered, SC.ContainerView has a property called nowShowing. When nowShowing changes, the ContainerView will replace its child view with whatever you pass in.

nowShowing can be either an SC.View or a string. Setting an SC.View is straightforward but boring; I presume the reason it didn't work for you was that it was probably handed a class instead of an instance.

More interestingly, you can also set nowShowing to a string. ContainerView will automatically evaluate that string when it changes. It supports your standard property path, so you can pass something like 'MyApp.viewsController.customView' and it will convert that to an object at runtime.

A quick aside about SC.Page: Any views instantiated from a Page have a property called page. Therefore, any view can reference the page by which it was created.

ContainerView leverages this by allowing you to set the nowShowing property to the name of another view that belongs to the same page.

What I like to do in my apps is define my mainPane in my mainPage. Usually that mainPane will have at least one container view. I then define any views I want to swap out as properties of the mainPage. Here's an example from a Twitter client I'm planning to release as sample code:

MyApp.mainPage = SC.Page.design({
  mainPane: SC.MainPane.design({
    childViews: 'contentView'.w(),

    contentView: SC.ContainerView.design({
      layout: { top: 70 }
    })
  }),

  loadingView: SC.View.design({
    childViews: 'spinner label'.w(),

    spinner: SC.ImageView.design({
      layout: { width: 32, height: 32, centerY: 0, centerX: -155 },
      value: sc_static('images/loading_large')
    }),

    label: SC.LabelView.design({
      layout: { height: 34, width: 280, centerY: 0, centerX: 20 },
      classNames: ['loading-label'],
      controlSize: SC.HUGE_CONTROL_SIZE,

      value: '_Loading Timeline…',
      localize: YES
    })
  })

Anyway, this can be tricky because it is non-obvious, but once you figure it out I think you'll see that it's really quite powerful stuff! Hope that helped.

-Tom

On Mar 31, 2010, at 7:40 AM, BinaryPalindrome wrote: