Deft 5-alpha impressions

163 views
Skip to first unread message

Ben Quarmby

unread,
Jul 10, 2014, 7:37:43 PM7/10/14
to def...@googlegroups.com
Thanks very much for releasing the Deft 5-alpha! It's allowed us to move forward with our planned upgrade to Ext 5.

Just thought I'd share my experiences so far:
  • Decided to create an Ext 5 app "shell" from scratch using Sencha Cmd 5, and port our app into it.
  • Added deft-debug.js to the "classpath" in app.json.
  • Didn't seem to need to pre-require Ext.ComponentQuery etc. like we did with Deft 0.9.
  • Extending from Deft.mvc.Application in our main app class seems to be enough to make all the other Deft classes available early.
  • Need to add Deft.mixin.Injectable to all our non-ViewController classes using "inject".
  • In the process of converting all our ViewController classes over to the Ext JS "control" and "reference" system.

On that last point, the Ext JS ViewController feels like a real step backwards from the Deft 0.9 VC design. Disappointing. Instead of promoting good itemId usage and a fantastic convention-over-configuration API (including auto-getters) there are new layers of abstraction that feel clunky and stringly-typed. The only advantage I've seen so far is that early component lifecycle events are available (i.e. beforerender).

Are there any plans to restore some of the original VC behavior?

Brian Kotek

unread,
Jul 10, 2014, 9:16:08 PM7/10/14
to deftjs
Great to hear! A few comments inline below...

On Thu, Jul 10, 2014 at 7:37 PM, Ben Quarmby <ben.q...@callmeqube.com> wrote:
Thanks very much for releasing the Deft 5-alpha! It's allowed us to move forward with our planned upgrade to Ext 5.

Just thought I'd share my experiences so far:
  • Decided to create an Ext 5 app "shell" from scratch using Sencha Cmd 5, and port our app into it.
  • Added deft-debug.js to the "classpath" in app.json.
  • Didn't seem to need to pre-require Ext.ComponentQuery etc. like we did with Deft 0.9.
Since we're piggybacking on the Sencha VC, we aren't using component queries to locate view items. So this is expected (and welcome). 
  • Extending from Deft.mvc.Application in our main app class seems to be enough to make all the other Deft classes available early.
  • Need to add Deft.mixin.Injectable to all our non-ViewController classes using "inject".
Right. Since Sencha doesn't support class preprocessors in Cmd, we had to revert back to the mixin approach to trigger dependency injection. 
  • In the process of converting all our ViewController classes over to the Ext JS "control" and "reference" system.

On that last point, the Ext JS ViewController feels like a real step backwards from the Deft 0.9 VC design. Disappointing. Instead of promoting good itemId usage and a fantastic convention-over-configuration API (including auto-getters) there are new layers of abstraction that feel clunky and stringly-typed. The only advantage I've seen so far is that early component lifecycle events are available (i.e. beforerender).

Are there any plans to restore some of the original VC behavior?


There really isn't. Personally, I agree that in some ways the approach Sencha has taken seems lacking compared to what Deft offered in the past. But in order to shoehorn the old functionality back in has two pretty big downsides:
  • It would be difficult to extend the Sencha VC class, since their class obviously works completely differently than the Deft 0.9 VCs. That would essentially mean having to re-implement all the other things their VC does as far as binding, ViewModel integration, and so on. At the least, this would be quite time-consuming. And at worst, it may just be impossible, since there are probably other parts of Ext JS that can only work with instances (or subclasses) of their class. 
  • It would force Deft users to diverge in a very fundamental way from how Ext JS itself works. We'd be very leery of introducing a split of that magnitude, where Deft works in a totally different way from Ext JS. And assuming that Touch will follow the same approach in the near future, that would only compound the problem. It would rapidly become a hellish Pandora's box.
For better and for worse, it makes sense to stay in sync with Sencha as much as possible, especially on something as fundamental as ViewControllers will be going forward. On the plus side, the Sencha VCs do have some pretty cool features (dropping the need for selectors, declarative event handlers, ViewModels, and so on). 

Brian

Ben Quarmby

unread,
Jul 10, 2014, 9:47:56 PM7/10/14
to def...@googlegroups.com
I get it. As an extension you really don't want to be fighting with the core framework. Better to play nice and remove the features that end up "first class", whatever shape they take.

Still, it's a testament to the original Deft VC design that Ext 5 feels a bit awkward by comparison.

FYI, our approach so far has been to use reference and listener definitions in the view where possible, and fall back to the "control" block and custom CQ getters if we must go deeper.

Depending on how things go, I may report back with our progress. May help others going through the same process.

Ben Quarmby

unread,
Jul 22, 2014, 5:30:33 PM7/22/14
to def...@googlegroups.com
Our upgrade to Ext and Deft 5 is nearly complete. The Deft JS 5 alpha has been rock solid so far, not a single related bug.

Full disclosure, Ext 5 has been quite painful. I have a list of bugs to report and lots of philosophical problems with their approach, but I wont bore you with that stuff.

As far as we're concerned, the Deft JS 5 alpha might as well be a release candidate. I think there might be some dead code in there, but other than that I can recommend the alpha it to anyone looking to upgrade to Ext JS 5.

Jean-Marc Choulet

unread,
Jul 23, 2014, 10:36:08 AM7/23/14
to def...@googlegroups.com
Here, we have a problem (ExtJS 5) with this code in a ViewModel:

myMenuStore: Ext.create ('MyApp.store.menu.Menu', { ...
our config....} ); --> error
We can not use our MyApp.store.menu.Menu class.
 
We must write:

     stores: {
         menu: {
             model 'MyApp.model.menu.Root'
             proxy: {
                 type: 'ajax'
                 url: '/ rest / menu'
                 reader: {
                     type: 'json',
                     rootProperty: 'items'
                 }
             }
         }
    }


It's really weird. How do you do ?

Thanks,

Jean-Marc

Brian Kotek

unread,
Jul 23, 2014, 11:19:19 AM7/23/14
to deftjs
I was also trying to play with this a while back. It seems like you can't use a specific Store class (or type) directly in the stores config. I was able to get it to work by setting the Store into the data and/or store object within the VM constructor though. If you want, you can take a look at the Fiddle I was using to test this: https://fiddle.sencha.com/#fiddle/53s

To be honest, one of the things that I'm still having trouble wrapping my head around in Ext 5 is the way they seem to want you to use Stores. Most (all?) of the examples seem to rely on Ext JS just generating a Store at runtime. It wants to draw the information to create a Store from things like a Model proxy config (or Schema config), Model associations, within View Models, and so on. It's almost like they never considered the fact that folks would need to use their own Store subclasses. And they also seem to assume that everyone always wants to just autoload their Store data...




--
Deft JS home page: http://deftjs.org/
Wiki: https://github.com/deftjs/DeftJS/wiki
For rules and tips on asking questions on the Deft JS mailing list: https://github.com/deftjs/DeftJS/wiki/Asking-Questions-on-the-Mailing-List
---
You received this message because you are subscribed to the Google Groups "Deft JS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to deftjs+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/deftjs/398cdb1e-c11a-469d-b184-14bdc5e797e7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Jean-Marc Choulet

unread,
Jul 23, 2014, 3:14:21 PM7/23/14
to def...@googlegroups.com
I tried with your code and after some tests :

In file MyApp/store/Menu.js

Ext.define('MyApp.store.Menu', {
    extend: 'Ext.data.Store',

    requires: [
        'MyApp.model.menu.Root'
    ],

    model: 'MyApp.model.menu.Root',

    proxy: {
        type: 'ajax',
        url: '/rest/menu',

        reader: {
            type: 'json',
            rootProperty: 'items'
        }
    }
});


In file MyApp/view/menu/MenuModel.js

Ext.define('MyApp.view.menu.MenuModel', {
    extend: 'Ext.app.ViewModel',
    alias: 'viewmodel.menu',

    requires: [
        'MyApp.store.Menu',
    ],

    constructor: function() {
        this.callParent(arguments);

        this.setStores({menu:{
                source: Ext.create('MyApp.store.Menu')
            }
        });
    }
});

In my ViewController :

...
    onPanelRender: function() {
        this.getView().getViewModel().getStore('menu').getSource().load(function(records, op, success) {
            ...
        });
....

For now, it works :)

Thanks,

Jean-Marc
Reply all
Reply to author
Forward
0 new messages