Listening for viewport about deftjs HOT 4 CLOSED

Deft JS's MVC model is intentionally different than the MVC implementation supplied by Sencha.

With Deft JS's MVC architecture, a ViewController is responsible for controlling only itself and its child components. It should never directly modify reference or modify any ancestor view or any arbitrary component via global selector. Instead, it should either dispatch events via its view that the ancestor view's view controller is listening for, or modify shared state that was either passed to it when instantiated via controllerConfig or that was injected into both view controllers. The ancestor view controller listens for events from its descendants (which may have associated view controllers that dispatch relevant events) or listen for change events from shared state. It then updates itself or its child components in reaction to those events.

In Deft JS, a View Controller controls a view (which can be any Ext.Container) and its child components. All selectors are defined relative to the controlled view.

In your case, it sounds like you are trying to create a Main ViewController, responsible for managing the viewport and its children. An Ext.container.Viewport is an Ext.Container subclass, so it can be controlled by a ViewController.

If you would like create a main view controller that is responsible for controlling the viewport, you'll want to add the Deft.mixin.Controllable mix-in to your Ext.container.Viewport subclass and specify your controller.

Ext.define( 'Users.controller.Main', {
  extend: 'Deft.mvc.ViewController',

  control: {
    view: { 
      // add any listeners, if needed
    }
  },

  init: function () {
    // NOTE: this.getView() will now return a reference to your viewport

    return this.callParent( arguments );
  }
});

Ext.define( 'Users.view.UsersViewport', {
  extend: 'Ext.container.Viewport',
  mixins: [ 'Deft.mixin.Controllable' ],
  controller: 'Users.controller.Main',

  ...
});

from deftjs.

Hi,

Thank you for your answers. Your explanation sounds perfect. I need to clarify some ideas:

• When you write

control: {
    view: { 
      // add any listeners, if needed
    }
  },

view is a reserved word that maps the controlled view? I've red this:

To listen to events dispatched by the view, use the view identifier:
......
NOTE: The getView() accessor is always available, regardless of whether you explicitly create a reference and add event listeners to view.

• Please tell me wheter are true or false the followings
• One view can have multiple ViewControllers
• Two views can have same ViewController

from deftjs.

Correct - view is essentially a reserved word.

A View class has only one View Controller class associated with it.

A View class references a View Controller class using the controller annotation, and when an instance of that View class is created, a corresponding instance of the View Controller class is created. When that View class instance is destroyed, its associated View Controller instance is destroyed as well. Each instance of the View class gets its own instance of the View Controller.

Two different View classes may reference the same View Controller class, but when instantiated those View classes will have different instances of the specified View Controller class.

In Deft JS v0.6.7, you use Deft.mixin.Controllable and the controller annotation on your View to specify its View Controller.

In Deft JS v0.8 (forthcoming - and currently available in development form from the master branch here on GitHub), the Deft.mixin.Controllable mix-in will be deprecated. You will still use the controller annotation to specify the associated View Controller for a View. However, this annotation will now be processed by a Sencha class preprocessor that will ensure that any subclasses of that view will also create the controller and getController() accessor prior to the subclass's constructor firing. Any subclass may optionally override the controller by specifying a different value.

Because Views are nested, a View might have descendants that are also Views with their own View Controllers. In this scenario, that View can define a reference to those descendant Views and listen for events dispatched by those Views.

Additionally, the View can use the reference it maintains for that descendant view to access its controller and call public methods.

  Ext.define( 'MyApp.controller.AccountsViewController', {
    extend: 'Deft.mvc.ViewController',

    control: {
      accountTree: {
        itemClick: 'onAccountTreeItemClick'
      }
    ...

    selectAccount: function( accountId ) {
      ...
    },

    ...

    onAccountTreeItemClick: function( component, record, row, event, eOpts ) {
      ...

      // A view controller can dispatch events via its associated view.
      this.getView().fireEvent( 'accountSelected', record );
    },

    ...
  });

  Ext.define( 'MyApp.controller.MainViewController', {
    extend: 'Deft.mvc.ViewController',

    control: {
      accountsView: {
        accountSelected: 'onAccountsViewAccountSelected'
      }
    },

    ...

    init: function () {
      ...

      // NOTE: you can use this.getAccountsView().getController() to access the child view's view controller
      var accountsViewController = this.getAccountsView().getController();
      accountsViewController.selectAccount( accountId );

      ...

      this.callParent( arguments );
    },    

    ...

    onAccountsViewAccountSelected: function( accountRecord ) {
      // TODO: react to event dispatched by the child view's view controller
    },

    ...
  });

So, to recap, a View Controller instance controls a specific View instance. It listens for events from the View, delegates work to injected Services (ex. Ext.data.Store, etc.) and updates the View and its child components to reflect state changes. The View Controller can dispatch events via its associated View to notify ancestor View Controllers of relevant changes. The View Controller can also expose a public API that ancestor View Controllers can use to interact with that View.

Together, a View and View Controller aggregates a collection components within a container to form a 'super component', with a higher level API (events and methods) than the individual components it is comprised of. A View is decoupled from its ancestors so that it can be instantiated multiple times and placed anywhere in a view hierarchy as needed.

from deftjs.

This will ensure that any subclasses of that view will also create the controller and getController() accessor prior to the subclass's constructor firing is great because now getController() is available also in initComponent.

That was another problem that I had till now.

from deftjs.