As a developer extending custom defined 'view' classes, Deft JS should recognize multiple controller(s) defined in the inheritance chain about deftjs HOT 7 CLOSED

The Deft-based applications I've built so far only specified the controller on the leaf nodes of the class inheritance hierarchy tree, so I hadn't considered this situation. Thanks for pointing this out.

My gut feeling is that the most specific controller (i.e. the controller specified for the subclass) should 'win'.

Given something like the following pseudo-code:

Ext.define( 'MyApp.controller.WorkspaceViewController', {
  extend: 'Deft.mvc.ViewController',
  ...
)};

Ext.define( 'MyApp.controller.EmbeddedViewController', {
  extend: 'MyApp.controller.WorkspaceViewController',
  ...
)};

Ext.define( 'MyApp.view.WorkspaceView', {
  extend: 'Ext.panel.Panel',
  controller: 'MyApp.controller.WorkspaceViewController',
  ...
)};

Ext.define( 'MyApp.view.EmbeddedView', {
  extend: 'MyApp.view.WorkspaceView',
  controller: 'MyApp.controller.EmbeddedViewController',
  ...
)};

then:

workspaceView = Ext.create( 'MyApp.view.WorkspaceView' ); 

should only create and attach a single instance of WorkspaceViewController, and

workspaceView.getController() 

should return an instance of WorkspaceViewController.

Similarly,

embeddedView = Ext.create( 'MyApp.view.EmbeddedView' );

should only create and attach a single instance of EmbeddedViewController, and

embeddedView.getController()

should return an instance of EmbeddedViewController.

Does that resonate with your expectations for how the framework would behave, too?

Imagining the code flow for the rework of the controller preprocessor I checked in yesterday with the intention of resolving issue #27, I can see where this would fail. With that implementation, I suspect both the subclass and superclass controllers would be created and attached, but only the superclass controller would be left accessible via getController(). That would definitely be wrong.

I'll look into this ASAP. Thanks for providing the tracing code, that should help.

Am I understanding the issue you reported correctly?

from deftjs.

Yes, you captured what our use case is.

We almost fully adopted Deft JS and is being used on a good sized project, around 500 Ext JS classes so far. Around 300 of those being framework or library classes. It's also being used with a backend system that we have very little control over, so we have to do quite a few client-side tricks to deliver a good user experience. So as you might imagine, between those two conditions, we use inheritance and the class system a lot to keep dry code.

Deft JS has been the tool that was missing as we started to adopt Ext JS 4 and it's MVC awkward implementation. I would strongly recommend adopting on a project, their are three developers assigned on this project and has made a big difference. So, thank you for all of your initial work and the last couple bug fixes. Were hiring! lol

from deftjs.

Back on the technical side of things here are a few use cases we identified that may or may not need to be addressed in the global. Also, because my project is from a enterprise/big company thing, I cannot share any of the code, unless it's on my own time, so I apologize for some of the ambiguity.

Here are two references from the Ruby/Rails world that we found to be helpful.

Ancestors/Dependents
https://github.com/rails/rails/blob/master/activesupport/lib/active_support/descendants_tracker.rb
Initialization
https://github.com/rails/rails/blob/master/railties/lib/rails/initializable.rb

Gaps

Where 1 and 3 have a controller, but 2 does not. We missed this use case internally, so mentioning it.

Multiple Inheritance

Yeah, it's an issue most places, but we have had to come up with ways to manually merge two branches of view controllers functionality into one.

Luckily, this has been rare so far, but as we move from more framework code, to feature/functionality, this will become a bigger issue. As currently it must be a single inheritance chain for each potential combination/branch

Injection-able Controllers

Sometimes we don't want to make two 'view interfaces', it would be nice to inject controllers based on conditions as well. We have the potential for 5 different user context scopes, we have worked around this so far (often some code duplication), but I am sure this will come up in the future where we need a good strategy.

ViewController Messaging/Coordination/Bubbling/Bus/Etc...

Not directly related, so I might open a separate ticket.

Basically something between Ext JS 4.x Monolith Controller/App approach and the light wight Deft JS View Controller.

First, there have been times where we have wanted to have better coordination between identical controllers. Use case, you have three grids, where now there are three view controller instances that each want to refresh from the server every 10 seconds. And the user could manually refresh at any time/for any grid. Ok, so we just addressed using random poll times and longer refreshes, but this highlights the need to expose or provide an interface for ViewController <to/from> ViewController. I don't see this solely as DeftJS area to solve, but it's closely tied.

Second, were currently researching patterns for delegation/routing/consumption from the ViewController as a 'producer' of indirect/emergent events itself (*ie, those related to the view, but not a direct 'click') and how we want to react/subscribe to those throughout the framework.

from deftjs.

I just saw your addendum with additional technical concerns; I skimmed it and will review at greater length as time allows this week.

Regarding gaps, I believe this fix will address that, but I should add a Jasmine test case to verify and cover that condition.

Regarding multiple inheritance, I'm curious how you have or are planning to implement that in the context of Sencha's class system.

Regarding injectable controllers, this raises some concerns that you may be putting too much logic into your View Controller. (Admittedly without knowing too much about your application's architecture) I would suggest considering a "thin controller, fat model" approach. The variability you describe should be handled in models and services that are injected into the controller. The controller's responsibility should be mediating user gestures by subscribing to UI component events and delegating work to those injected model and service objects (and updating the UI with the results where necessary).

Regarding ViewController messaging and coordination - that is an area where I'm currently doing some research, design and architecture work toward future improvements to our ViewController very much along those lines. Given the scope of your Deft JS-based project, (if you are willing) I would definitely like to reach out to you later this week to collect your feedback and help validate our future direction on this.

from deftjs.

There are some scenarios where omitting a controller within the inheritance chain does not result in the expected behavior.

In all cases, including subclasses that do not specify a controller, this.getController() should be valid.

from deftjs.

The previously referenced commit broke this.callParent() functionality for classes that use both the inject and controller class annotation. This is caused by the lack of Sencha class system book-keeping metadata on manually added interceptor functions (ex. $previous, $owner).

from deftjs.

Refactored the inject and controller class preprocessors to leverage Ext.Base::override() to intercept and override class constructors.

Added additional facade methods to Deft.Class to smooth out differences between Ext JS 4.0 and Ext JS 4.1 / Sencha Touch 2.0's APIs.

from deftjs.