1. #1
    Sencha User
    Join Date
    Sep 2010
    Posts
    69
    Vote Rating
    0
    mboreback is on a distinguished road

      0  

    Default What is best practise for event management in architect?

    What is best practise for event management in architect?


    Sencha Architect offers the ability to define events on components in a view and at the same time I here that event management shall be done in a controller.

    From a architect GUI perspective I like to keep the events in the view, but I have hered that there is performance issues doing it that way.

    Can anyone explane the pros and cons for defining event listener in the view in architect?

  2. #2
    Sencha Premium Member
    Join Date
    May 2010
    Location
    Guatemala, Central America
    Posts
    1,267
    Vote Rating
    81
    ssamayoa is a jewel in the rough ssamayoa is a jewel in the rough ssamayoa is a jewel in the rough ssamayoa is a jewel in the rough

      0  

    Default


    From a architect GUI perspective I like to keep the events in the view


    Which could lead to spaguetti code. Take a look to MVC.

    but I have hered that there is performance issues doing it that way.


    Performance in client side code is the less of your problems.

    Can anyone explane the pros and cons for defining event listener in the view in architect?


    There is no black or white, as all in the life "it depends".

    Regards.
    UI: Sencha Architect 3.x / ExtJS 4 & 5
    Server side: JEE / EJB 3.x / CDI / JPA 2.x/ JAX-RS / JasperReports
    Application Server: Glassfish / WildFly
    Databases: Oracle / DB2 / MySQL / Firebird

    If you like my answer please vote!

  3. #3
    Sencha Premium Member
    Join Date
    Nov 2007
    Posts
    79
    Vote Rating
    4
    oldroy is on a distinguished road

      1  

    Default this.fireEvent

    this.fireEvent


    Hello,
    It seems to me that in small applications you can do almost anything and get away with it. As long as you think through your way of configuring things and stick with that way, you're OK.

    However, with large applications, so far it has worked better for me to handle event in the views by sending "custom events" that can be listened for and handled in the controller. Very often you will be having several events in the view that will be doing the same thing and will overlap. Best way is to handle them by pointing to the same view function that fires the same event so that you don't have to handle the same thing twice at the controller level.

    My rule of thumb so far is that if something deals with data, set up a fireEvent and handle it in the controller. If you are just doing something in the view, show, hide, animate, etc. that doesn't deal with data, listen and handle the whole thing in the view.

    For example, a button click in the view:

    Code:
    xtype: "button",
    etc.,
    listeners: {
       click: {
             fn: me.onIWantANewThing,
             scope: me
         }
    }
    
    onIWantANewThing: function(button, e, options) {
           this.fireEvent(newThingCommand, this)
    }
    //fromt his point any other events, like a menu item that would do the same thing 
    //you can point to onIWantANewThing:
    
    //In your controller:
    //Set up your references for your view, add view ref and listener as controller 
    //action. Or control by ID - but if you control by id you are defeating the purpose 
    //of decoupling the view from the controller. Yeah, sometimes you have to write 20 
    //lines of code to decouple something you only had to write 5 lines of code to do - 
    //your mileage may vary on decoupling....
    
    init: function() {
      this.control({
        mythingview: {
           newThingCommand: this.onNewThingCommand,
           etc.
    }
    })
    
    onNewThingCommand: function(vars) {
       do stuff
    }
    The best discussion and actual code so far to learn more about this is MiamiCoder's excellent new senchatouch2 ebook. Costs is reasonably low for what you learn. Just go to miamicoder.com. I would start there, it's time and money well spent. Everything he does in his book also applies also to EXTJS 4.1 - there really is not that much that is different in my opinion.

    Keep in mind that this whole MVC system is new. What we call best practises now will evolve quickly. And some things you can do easily freehand in code, are still a wee bit difficult to do in Architect 2 - but the architect team is working on all of that.

    Just my two cents.....

    My hope is that this will be an ongoing and lively discussion. Best practises and examples are the thing we need the most to use architect and mvc more effectively.

  4. #4
    Sencha User
    Join Date
    Sep 2010
    Posts
    69
    Vote Rating
    0
    mboreback is on a distinguished road

      0  

    Default


    I have purshased the book you sugested, and have started to read it, I hope it turnes out to be educating.

    I am far from the skill level I like to have when it comes to sencha and javascript, but I am willing to share my work to educate other people, and to shorten down the learning curve.

    There is a lot of opinons when it comes to writing code, I spoke to one person that said that if the event management was kept in the view the performnce was degradating, and it was harder for the browser to swap out code that was not in use. But if the code was maintained in the controller, the performance should be better.

    But from a Architect 2 perspective it is a lot easier to follow the code if the majority of the code is directly attached to the object, like buttons, and controlling what objects are showned.
    And just the overall application controle are stored in controllers.

  5. #5
    Sencha User
    Join Date
    Sep 2010
    Posts
    69
    Vote Rating
    0
    mboreback is on a distinguished road

      0  

    Default


    The book was good.

    Using controllers, is adding far more coding than just defining the events in the view.
    And from a readbility perspective I do not agree that controller offers more readable code.
    But I understand that the common trend is to separate logig from the view, and that is probably very good.
    I would say that there is component logic and application logic, application logic is inter application controle and component logic is internat component stuff like hiding buttons, or going backward to previous view, whiles application logic is the implementation of this component in this application.
    So from a reusability persective the view should contrain all component based logic and the implementation should be done in the controller.
    Or as an alternative have a component cotroller that is reusable , and a second controller for implementation.

    But beside this is there any performance issues placing code in the view compared to moving them to the controller.

  6. #6
    Sencha Premium Member dawesi's Avatar
    Join Date
    Mar 2007
    Location
    Melbourne, Australia (aka GMT+10)
    Posts
    1,083
    Vote Rating
    44
    dawesi has a spectacular aura about dawesi has a spectacular aura about

      0  

    Default


    Quote Originally Posted by mboreback View Post
    The book was good.

    Using controllers, is adding far more coding than just defining the events in the view.
    And from a readbility perspective I do not agree that controller offers more readable code.
    But I understand that the common trend is to separate logig from the view, and that is probably very good.
    I would say that there is component logic and application logic, application logic is inter application controle and component logic is internat component stuff like hiding buttons, or going backward to previous view, whiles application logic is the implementation of this component in this application.
    So from a reusability persective the view should contrain all component based logic and the implementation should be done in the controller.
    Or as an alternative have a component cotroller that is reusable , and a second controller for implementation.

    But beside this is there any performance issues placing code in the view compared to moving them to the controller.
    I would disagree with you on it adding more code than a view. Refs give you shortcuts that make coding heaps easier and shorter. You have to choose to change your mindset on how to code controllers and learn the shortcuts that assist greatly in reducing code, which leads to your understanding the Architecture of an app better, so that multiple different event architectures can be applied to the same view to give it different functionality.

    Putting your logic into your view hardwires the functionality and re-usability of that you say you're looking for?? I'm confused.

    Putting your component logic into your view defeats the whole point of using MVC.
    Teahouse Training Company
    Official Certified Sencha Trainer

    Australia / New Zealand / Singapore / Hong Kong & APAC



    SenchaWorld.com - Sencha webinars, videos, etc
    SenchaForge.org - (coming soon)
    TeahouseHQ.com - Sencha ecosystem training portal

    Code Validation : JSLint | JSONLint | JSONPLint

  7. #7
    Sencha Premium Member
    Join Date
    May 2010
    Location
    Guatemala, Central America
    Posts
    1,267
    Vote Rating
    81
    ssamayoa is a jewel in the rough ssamayoa is a jewel in the rough ssamayoa is a jewel in the rough ssamayoa is a jewel in the rough

      0  

    Default


    As I said before, there is no "black or white".

    Let me tell you why:

    I crafted my first ExtJS 4 application "by hand". At that time Architect didn't exists.

    I use extensively inheritance (Architect still very young in that area) in views and controllers. The separation of view code and logic code in two separated files were very beneficial because is easier to edit and maintain. Remember, was "by hand". When I have to put logic code in the views was with multiple instances of a view must be active at same time. You can't do that with MVC.

    I crafted my second ExtJS 4 application with SA. This application was less complex than first one and I didn't need multiple instance views/controllers. But what I used a lot this time was composition: Smaller, reusable views used in different containers. Logic over that views sometimes was almost the same while other times were completely different. And I have an special case in which the view has the logic because limitations on inheritance in controllers: A "wizard" panel.

    The bottom line is that there is no "golden" rule of "to use or not use be MVC" (to be or no to be...). It depends on the problem and tools at hand. The only advice I can give to you: If you can use MVC, do that.

    Finally, forget about performance. That should be the least of your concerns. You are anticipating a problem that may not even happens. Focus on crafting your product/solution. From "Efective Java 2nd Edition":

    There are three aphorisms concerning optimization that everyone should know.
    They are perhaps beginning to suffer from overexposure, but in case you aren’t yet
    familiar with them, here they are:


    More computing sins are committed in the name of efficiency (without necessarily
    achieving it) than for any other single reason—including blind stupidity.
    —William A. Wulf [Wulf72]


    We should forget about small efficiencies, say about 97% of the time: premature
    optimization is the root of all evil.
    —Donald E. Knuth [Knuth74]


    We follow two rules in the matter of optimization:
    Rule 1. Don’t do it.
    Rule 2 (for experts only). Don’t do it yet—that is, not until you have a
    perfectly clear and unoptimized solution.
    —M. A. Jackson [Jackson75]

    Note the last one...

    Regards.
    UI: Sencha Architect 3.x / ExtJS 4 & 5
    Server side: JEE / EJB 3.x / CDI / JPA 2.x/ JAX-RS / JasperReports
    Application Server: Glassfish / WildFly
    Databases: Oracle / DB2 / MySQL / Firebird

    If you like my answer please vote!

  8. #8
    Sencha User
    Join Date
    Jul 2012
    Posts
    14
    Vote Rating
    1
    alexandrn is on a distinguished road

      0  

    Default


    I'm trying to fire and subscribe for custom events in SA2, b424, and nothing has been working yet.

    Have you registered the "newThingCommand" event somewhere else?
    Have you changed any options regarding bubbling events?


    Quote Originally Posted by oldroy View Post
    Hello,
    It seems to me that in small applications you can do almost anything and get away with it. As long as you think through your way of configuring things and stick with that way, you're OK.

    However, with large applications, so far it has worked better for me to handle event in the views by sending "custom events" that can be listened for and handled in the controller. Very often you will be having several events in the view that will be doing the same thing and will overlap. Best way is to handle them by pointing to the same view function that fires the same event so that you don't have to handle the same thing twice at the controller level.

    My rule of thumb so far is that if something deals with data, set up a fireEvent and handle it in the controller. If you are just doing something in the view, show, hide, animate, etc. that doesn't deal with data, listen and handle the whole thing in the view.

    For example, a button click in the view:

    Code:
    xtype: "button",
    etc.,
    listeners: {
       click: {
             fn: me.onIWantANewThing,
             scope: me
         }
    }
    
    onIWantANewThing: function(button, e, options) {
           this.fireEvent(newThingCommand, this)
    }
    //fromt his point any other events, like a menu item that would do the same thing 
    //you can point to onIWantANewThing:
    
    //In your controller:
    //Set up your references for your view, add view ref and listener as controller 
    //action. Or control by ID - but if you control by id you are defeating the purpose 
    //of decoupling the view from the controller. Yeah, sometimes you have to write 20 
    //lines of code to decouple something you only had to write 5 lines of code to do - 
    //your mileage may vary on decoupling....
    
    init: function() {
      this.control({
        mythingview: {
           newThingCommand: this.onNewThingCommand,
           etc.
    }
    })
    
    onNewThingCommand: function(vars) {
       do stuff
    }
    The best discussion and actual code so far to learn more about this is MiamiCoder's excellent new senchatouch2 ebook. Costs is reasonably low for what you learn. Just go to miamicoder.com. I would start there, it's time and money well spent. Everything he does in his book also applies also to EXTJS 4.1 - there really is not that much that is different in my opinion.

    Keep in mind that this whole MVC system is new. What we call best practises now will evolve quickly. And some things you can do easily freehand in code, are still a wee bit difficult to do in Architect 2 - but the architect team is working on all of that.

    Just my two cents.....

    My hope is that this will be an ongoing and lively discussion. Best practises and examples are the thing we need the most to use architect and mvc more effectively.

  9. #9
    Sencha User
    Join Date
    Sep 2010
    Posts
    69
    Vote Rating
    0
    mboreback is on a distinguished road

      0  

    Default


    I am migrating all my projects to the MVC standard.
    The refs is good.
    But creatingthe controller in architect is more work than just press the button and add the event on the component, architect is adding all the stuff you manualy has to add in the controller.
    The pros of this is that if I rename the id of the component, the event will still work fine, but the controller will not.
    I am unsure why sencha is providing a such nice way to manage the events in architect, but at the same time say that it is not what we want.
    The best might be from an architect developer perspective and readability perspective that architect, was generating the controller and place the compoentns events in that. And also generate the controller object by automation so it is possible to add ther staff inthere.

  10. #10
    Sencha User
    Join Date
    Sep 2010
    Posts
    69
    Vote Rating
    0
    mboreback is on a distinguished road

      0  

    Default


    This did not work for me ether.

    Quote Originally Posted by alexandrn View Post
    I'm trying to fire and subscribe for custom events in SA2, b424, and nothing has been working yet.

    Have you registered the "newThingCommand" event somewhere else?
    Have you changed any options regarding bubbling events?