1. #1
    Sencha Premium Member
    Join Date
    Apr 2008
    Posts
    231
    Vote Rating
    19
    themightychris will become famous soon enough themightychris will become famous soon enough

      0  

    Default Should views or controllers manipulate the DOM?

    Should views or controllers manipulate the DOM?


    I'm having trouble picking between two approaches to controllers vs views in ExtJS4... my projects are in various states of adhering to one or the other:

    Dumb views
    Views contain no procedural code at all outside maybe an initComponent override that applies default configs. The view is mostly only lazy components specs and config options. This approach seems to lend itself well to using a tool like Designer to generate view classes that can be dropped in with your controller with no changes or letting human designers manage views without tripping over code.

    DOMless controllers
    Controllers know nothing of CSS classes and DOM structure and only handle application-level logic and coordination between views. Views contain as little procedural code as possible, doing just enough to turn DOM events into higher-level component events and to encapsulate reading/updating their state.

    I'm wondering if anyone has committed to one for awhile and has anything feelings to share on where it got them?

    DOMless controllers seems like a cleaner separation of concerns, but dumb views might offer a more convenient workflow. I've also seen another pattern from I think the old version of designer where components are split into two classes: a UI layer and then a logic layer that extends it. Has anyone tried mixing that approach with ExtJS4s MVC structure?
    Chief Architect @ Jarv.us Innovations
    Co-captain @ Code for Philly
    Co-founder @ Devnuts - Philadelphia Hackerspace

  2. #2
    Ext JS Premium Member westy's Avatar
    Join Date
    Feb 2009
    Location
    Bath, UK
    Posts
    839
    Vote Rating
    39
    westy is a jewel in the rough westy is a jewel in the rough westy is a jewel in the rough

      0  

    Default


    Hi,

    With Ext nothing really needs to know about the underlying DOM really (especially in version 4), at most things have to be able to reference other object using component queries, by type normally. So searching for an owning window of a calling component, say, using the 'up' method.

    That said sometimes it's unavoidable if you want to do something very specific.

    The current product I'm working on is pretty mature now (just shipping first version for integration development to start now), and we've gone with the minimal code in views option I'd say.

    That said our controllers are nothing like how Ext MVC recommends since in my experience it simply didn't work, and when I highlighted this nobody took a blind bit of notice, so I worked around it as I saw fit, and that's what we've used ever since.

    The whole plan of wiring up views to their controllers in an init method that uses component query to reference controls is flawed, since when the controllers are inited by the application a lot of the views will not exist, especially when using a viewport with a card layout...

    Our controllers have ended up being a collection of static methods, and our views simply call the method they need when they get the event they're concerned with.
    It's not great, and I intend to look at it again, but we're far too late in the stage with this one to change it I think...

    Hope this helps, and apologies if it's not very clear.

    Westy
    Product Architect
    Altus Ltd.

  3. #3
    Sencha Premium Member
    Join Date
    Apr 2008
    Posts
    231
    Vote Rating
    19
    themightychris will become famous soon enough themightychris will become famous soon enough

      0  

    Default


    Thanks for the input westy. My applications make heavy use of tpl/renderTpl to create custom UIs so I can't avoid the DOM like I could building purely with Ext components.

    Quote Originally Posted by westy View Post
    The whole plan of wiring up views to their controllers in an init method that uses component query to reference controls is flawed, since when the controllers are inited by the application a lot of the views will not exist, especially when using a viewport with a card layout...
    It actually doesn't matter when the views are created, the component queries used in this.control are used to match component events as they are fired, not when you call this.control. I've really enjoyed using controllers in this manor... think of it more like setting up global event filters than attaching listeners.

    It would be really cool actually if components supported a mechanism like this.control for DOM events that could be used with renderTpl/renderSelectors
    Chief Architect @ Jarv.us Innovations
    Co-captain @ Code for Philly
    Co-founder @ Devnuts - Philadelphia Hackerspace

  4. #4
    Sencha Premium Member vadimv's Avatar
    Join Date
    Sep 2010
    Location
    Chisinau, Moldova
    Posts
    642
    Vote Rating
    25
    vadimv will become famous soon enough vadimv will become famous soon enough

      0  

    Default


    Hi guys,

    want to share with you my approach: my last app is based on card layout. It has a few views and one controller, the controller it's sort of a coordinator between the views(panels and dataviews, with templates), also the controller contains views events where is easier to reference other views/components or build the logic which depends on other components. In the views beside the initComponent and cfg part I have the UI logic which is specific to it and controls the rendering and the handles users input/output data.

    This approach works perfectly for me, don't understand the problem on what @westy said about "whole plan".

    I think it depends on the app in achieving clean dumb views, it's a good idea to have them(and working with the Designer), and have DOMless controllers.
    But so far I achieved almost "a separation" with a little mix of both, because there's user's input/output data which I keep it in the view. Of course working and trying to achieve the layering pattern as much as possible because in this way you get a easy to maintain, flexible and modular app structure.

    Also nice post, would be great to hear other opinions and approaches from other experienced users.
    Vadim.

  5. #5
    Ext JS Premium Member westy's Avatar
    Join Date
    Feb 2009
    Location
    Bath, UK
    Posts
    839
    Vote Rating
    39
    westy is a jewel in the rough westy is a jewel in the rough westy is a jewel in the rough

      0  

    Default


    Quote Originally Posted by themightychris View Post
    It actually doesn't matter when the views are created, the component queries used in this.control are used to match component events as they are fired, not when you call this.control. I've really enjoyed using controllers in this manor... think of it more like setting up global event filters than attaching listeners.
    Ah right, well it didn't seem to work like that when Ext.dispatch was removed in a very early version, so I found a speedy workaround. Sounds like I need to revisit it when I get the chance and see how it pans out.

    Cheers,
    Westy
    Product Architect
    Altus Ltd.

Thread Participants: 2