You found a bug! We've classified it as DSGNR-3733 . We encourage you to continue the discussion and to find an acceptable workaround while we work on a permanent fix.
  1. #1
    Sencha Premium Member lorezyra's Avatar
    Join Date
    Dec 2007
    Location
    Japan -- 日本
    Posts
    638
    Vote Rating
    18
    lorezyra will become famous soon enough lorezyra will become famous soon enough

      0  

    Default multiple Controller Actions can not reference existing function

    multiple Controller Actions can not reference existing function


    REQUIRED INFORMATION Architect Build tested:
    • Build: 908
    Project Type:
    • ExtJS 4.1
    Description:
    • I have various actions that should call the same function already defined and assigned to another action. However, when I attempt to assign my second action the same function name, it returns an error: "This handler name (fn) is already in use or is reserved. Please use a unique name."
    • Why is this required? Why should I have to create several functions that do nothing more than reference another function? Why can I not simply have the action call the existing function directly. When I type the code out manually, it works in ExtJS 4.0 & 4.1...
    • This is what I'm trying to get SA to produce:
      PHP Code:
          init: function () {
              if (
      Ext.isGecko && debug){ console.log(" usrMangerTAB.controllerInit()"); }
              var 
      me=this;

              
      this.control({
                  
      'panel[itemId=usrMangerTAB]': { //tabPanel object
                      
      containercontextmenume.cancelContextMenu
                  
      },
                  
      '[itemId=UserViewPanelGrpAdd]': {
                      
      clickme.userViewPanelGrpAddOnClick,
                      
      contextmenume.cancelContextMenu
                  
      },
                  
      '[itemId=UserViewPanelGrpDel]': {
                      
      clickme.userViewPanelGrpDelOnClick
                  
      },
                  
      '[itemId=UserViewPanelGrpSaves]': {
                      
      clickme.UserViewPanelGrpSavesOnClick
                  
      },
                  
      '[itemId=UserViewPanelGrpBBSaves]': {
                      
      clickme.UserViewPanelGrpSavesOnClick
                  
      },
                  
      '[itemId=UserViewPanelGrpReload]': {
                      
      clickme.UserViewPanelGrpReloadOnClick
                  
      },
                  
      '[itemId=UserViewPanelGrpForget]': {
                      
      clickme.UserViewPanelGrpForgetOnClick
                  
      },
                  
      '[itemId=UserViewPanelGrpBBForget]': {
                      
      clickme.UserViewPanelGrpForgetOnClick
                  
      },
                  
      '[itemId=grpViewPanel]': {//grid object
                      
      itemcontextmenume.grpViewPanelRclk,
                      
      containercontextmenume.cancelContextMenu
                  
      },


      //// the rest of the controller continues on... 
    Steps to reproduce the problem:
    • Create view components and controller
    • reference view components
    • create controller action for each component (in my case a toolbar button)
    • Since both buttons perform the same function, assign same function (glue) name.
    • See error
    The result that was expected:
    • Should allow the action to be assoicated with any existing function without forcing a new function to be created.
    The result that occurs instead:
    • annoying error
    HELPFUL INFORMATION Screenshot, Project, or Video:
    • n/a
    Possible fix:
    • If the referenced function is an existing function name, simply tie the action to that function. Don't try to create a new controller function with same name...
    Operating System:
    • OSX 10.8.3
    Perfection as a goal is a nice idea that can point one in a specific direction. However, since "perfection" is an ever changing (evolving?) and moving target, one must admit that perfection can never be obtained...

    When in doubt, check the d4mn source code!
    ================================================
    And here are my terms...
    1. I don't care if you use my source code. (Known as "Code.")
    2. I don't care if I get any monetary compensation.
    3. I do care to receive credit for Code provided. So, please keep my name in the comments for Code provided.
    4. Code is provided without warranty "AS-IS" and I claim absolutely no warranty nor liability to the quality, security, and run-ability on any platform.
    5. By using Code, you accept all risk inherit with Code regardless if Code has known and yet to be discovered bugs.
    6. You are welcome to change and improve the Code to best meet your needs.
    7. I don't care if you use the Code in a commercial or open-source project.
    8. You are not required to contact me prior to using the Code.
    ================================================
    Simple. Enjoy.

  2. #2
    Sencha - Architect Dev Team aconran's Avatar
    Join Date
    Mar 2007
    Posts
    9,413
    Vote Rating
    129
    aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold

      0  

    Default


    This is currently by design.

    A simple workaround would be to put an additional attribute on each of these views, perhaps "action=userview" and then use a controlQuery that checks for that.

    Possibly down the line we will allow users to assign multiples and either prompt them or have a configuration to turn this off.
    Aaron Conran
    @aconran
    Sencha Architect Development Team

  3. #3
    Sencha Premium Member lorezyra's Avatar
    Join Date
    Dec 2007
    Location
    Japan -- 日本
    Posts
    638
    Vote Rating
    18
    lorezyra will become famous soon enough lorezyra will become famous soon enough

      0  

    Default


    I find this "feature" very annoying...

    It would reduce my workflow if I didn't have to constantly call the function inside the uniquely named function. It's a waste of time and adds to the call stack. Why not allow the function to be called directly? Especially if you have already defined the function in question?



    For example: (My use case)
    The majority of my function reuse is from preventing the user from right-clicking any part of the GUI. I write the contextmenu function once, and call it when the user makes the action I'm looking for (container, panel, grid, etc).

    Why must I make a 100 functions to call that single function???
    Why can't I just have SA directly reference that same existing function???
    Perfection as a goal is a nice idea that can point one in a specific direction. However, since "perfection" is an ever changing (evolving?) and moving target, one must admit that perfection can never be obtained...

    When in doubt, check the d4mn source code!
    ================================================
    And here are my terms...
    1. I don't care if you use my source code. (Known as "Code.")
    2. I don't care if I get any monetary compensation.
    3. I do care to receive credit for Code provided. So, please keep my name in the comments for Code provided.
    4. Code is provided without warranty "AS-IS" and I claim absolutely no warranty nor liability to the quality, security, and run-ability on any platform.
    5. By using Code, you accept all risk inherit with Code regardless if Code has known and yet to be discovered bugs.
    6. You are welcome to change and improve the Code to best meet your needs.
    7. I don't care if you use the Code in a commercial or open-source project.
    8. You are not required to contact me prior to using the Code.
    ================================================
    Simple. Enjoy.

  4. #4
    Sencha Premium Member lorezyra's Avatar
    Join Date
    Dec 2007
    Location
    Japan -- 日本
    Posts
    638
    Vote Rating
    18
    lorezyra will become famous soon enough lorezyra will become famous soon enough

      0  

    Default


    Why don't you guys do the same thing with controller actions as you do with adding stores to the controller that are already defined in the application?


    Why not give us the option to directly reference an existing function? (As you do with stores?)
    Attached Images
    Perfection as a goal is a nice idea that can point one in a specific direction. However, since "perfection" is an ever changing (evolving?) and moving target, one must admit that perfection can never be obtained...

    When in doubt, check the d4mn source code!
    ================================================
    And here are my terms...
    1. I don't care if you use my source code. (Known as "Code.")
    2. I don't care if I get any monetary compensation.
    3. I do care to receive credit for Code provided. So, please keep my name in the comments for Code provided.
    4. Code is provided without warranty "AS-IS" and I claim absolutely no warranty nor liability to the quality, security, and run-ability on any platform.
    5. By using Code, you accept all risk inherit with Code regardless if Code has known and yet to be discovered bugs.
    6. You are welcome to change and improve the Code to best meet your needs.
    7. I don't care if you use the Code in a commercial or open-source project.
    8. You are not required to contact me prior to using the Code.
    ================================================
    Simple. Enjoy.

  5. #5
    Sencha - Architect Dev Team aconran's Avatar
    Join Date
    Mar 2007
    Posts
    9,413
    Vote Rating
    129
    aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold

      0  

    Default


    The biggest reason is just to prevent mistakes. Perhaps if this restriction was further enforced with either the events being different or the method signatures being different then I think that would be good...

    ie not allowing a user to bind a selectionchange event and a show event to the same method (as we have no idea which signature they'd want to use)
    Aaron Conran
    @aconran
    Sencha Architect Development Team

  6. #6
    Sencha Premium Member lorezyra's Avatar
    Join Date
    Dec 2007
    Location
    Japan -- 日本
    Posts
    638
    Vote Rating
    18
    lorezyra will become famous soon enough lorezyra will become famous soon enough

      0  

    Default


    That as way too restrictive!


    If the framework supports it, why limit it in SA?
    I respect the need for implementing (and encouraging) best practice use through SA. However, there are many edge cases that make SA less valuable if I expect to use it as an all-inclusive IDE.

    Let the user make mistakes, but don't crash SA or prevent us from implementing it as long as it adheres to the ExtJS framework.

    I think the app can be more valuable if it's informative and not restrictive...
    Perfection as a goal is a nice idea that can point one in a specific direction. However, since "perfection" is an ever changing (evolving?) and moving target, one must admit that perfection can never be obtained...

    When in doubt, check the d4mn source code!
    ================================================
    And here are my terms...
    1. I don't care if you use my source code. (Known as "Code.")
    2. I don't care if I get any monetary compensation.
    3. I do care to receive credit for Code provided. So, please keep my name in the comments for Code provided.
    4. Code is provided without warranty "AS-IS" and I claim absolutely no warranty nor liability to the quality, security, and run-ability on any platform.
    5. By using Code, you accept all risk inherit with Code regardless if Code has known and yet to be discovered bugs.
    6. You are welcome to change and improve the Code to best meet your needs.
    7. I don't care if you use the Code in a commercial or open-source project.
    8. You are not required to contact me prior to using the Code.
    ================================================
    Simple. Enjoy.

  7. #7
    Sencha - Architect Dev Team aconran's Avatar
    Join Date
    Mar 2007
    Posts
    9,413
    Vote Rating
    129
    aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold

      0  

    Default


    So we assign two events with completely different signatures; remember Sencha Architect generates the signatures... which one do we use?

    Do we keep the existing signature and let the other events that come in be completely wrong and crash the app when they are used? For example using e.getTarget() when e turns out to be a selection model?

    Or do we wipe out the entire signature and say you can't use arguments? What if a user is using one of those arguments?

    Letting different event types trigger the same method and using their arguments is a bad practice. This is what we're trying to prevent.
    Aaron Conran
    @aconran
    Sencha Architect Development Team

  8. #8
    Sencha Premium Member lorezyra's Avatar
    Join Date
    Dec 2007
    Location
    Japan -- 日本
    Posts
    638
    Vote Rating
    18
    lorezyra will become famous soon enough lorezyra will become famous soon enough

      0  

    Default


    Quote Originally Posted by aconran View Post
    So we assign two events with completely different signatures; remember Sencha Architect generates the signatures... which one do we use?

    Do we keep the existing signature and let the other events that come in be completely wrong and crash the app when they are used? For example using e.getTarget() when e turns out to be a selection model?

    Or do we wipe out the entire signature and say you can't use arguments? What if a user is using one of those arguments?

    Letting different event types trigger the same method and using their arguments is a bad practice. This is what we're trying to prevent.
    I appreciate that you feel SA should hold the user's hand and instruct them where they are failing to create proper code... I have yet to see an IDE that did my job for me...

    However, the assumption should be that you already know the framework when you use SA.
    So, if the user creates controller actions that point to the same declared function... SA should not throw a fit about it. Perhaps provide a warning/notice that a unique function is recommended instead of outright prohibiting it.


    Yes, I know this opens the gate for users to attach a selectchange action to the same function as a contextmenu action. Not that I would want to do that. But I have at least two use cases where it's far better to point to an existing function from two "different" actions than it is to create three functions that all point to one function (using same parameters).

    First use-case: prevent right-click (contextmenu) on any component in the app. I don't want the user to have access to the browser's default context-menu. Handle only the right-clicks that I want to display a menu on...

    Second use-case: I have a layout where a hidden top toolbar has a button to perform some action. And, I have a bottom pagebar for a grid with the same button copied. This would show up in the controller as two different actions, but they both perform the exact same function.
    Perfection as a goal is a nice idea that can point one in a specific direction. However, since "perfection" is an ever changing (evolving?) and moving target, one must admit that perfection can never be obtained...

    When in doubt, check the d4mn source code!
    ================================================
    And here are my terms...
    1. I don't care if you use my source code. (Known as "Code.")
    2. I don't care if I get any monetary compensation.
    3. I do care to receive credit for Code provided. So, please keep my name in the comments for Code provided.
    4. Code is provided without warranty "AS-IS" and I claim absolutely no warranty nor liability to the quality, security, and run-ability on any platform.
    5. By using Code, you accept all risk inherit with Code regardless if Code has known and yet to be discovered bugs.
    6. You are welcome to change and improve the Code to best meet your needs.
    7. I don't care if you use the Code in a commercial or open-source project.
    8. You are not required to contact me prior to using the Code.
    ================================================
    Simple. Enjoy.

  9. #9
    Sencha Premium Member lorezyra's Avatar
    Join Date
    Dec 2007
    Location
    Japan -- 日本
    Posts
    638
    Vote Rating
    18
    lorezyra will become famous soon enough lorezyra will become famous soon enough

      0  

    Default


    Here's an idea...


    If you insist that users must not mix EventBinding when calling different functions, why not allow users to point to functions that serve the same EventBinding name? ]

    For example: User creates an action that has the EventBinding of containercontextmenu, then allow the same function to be associated with any action using the same EventBinding.

    This way we know the function should handle the same arguments (same order, type, etc) as the original function.
    Perfection as a goal is a nice idea that can point one in a specific direction. However, since "perfection" is an ever changing (evolving?) and moving target, one must admit that perfection can never be obtained...

    When in doubt, check the d4mn source code!
    ================================================
    And here are my terms...
    1. I don't care if you use my source code. (Known as "Code.")
    2. I don't care if I get any monetary compensation.
    3. I do care to receive credit for Code provided. So, please keep my name in the comments for Code provided.
    4. Code is provided without warranty "AS-IS" and I claim absolutely no warranty nor liability to the quality, security, and run-ability on any platform.
    5. By using Code, you accept all risk inherit with Code regardless if Code has known and yet to be discovered bugs.
    6. You are welcome to change and improve the Code to best meet your needs.
    7. I don't care if you use the Code in a commercial or open-source project.
    8. You are not required to contact me prior to using the Code.
    ================================================
    Simple. Enjoy.

  10. #10
    Sencha - Architect Dev Team aconran's Avatar
    Join Date
    Mar 2007
    Posts
    9,413
    Vote Rating
    129
    aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold

      0  

    Default


    Quote Originally Posted by lorezyra View Post
    If you insist that users must not mix EventBinding when calling different functions, why not allow users to point to functions that serve the same EventBinding name? ]

    For example: User creates an action that has the EventBinding of containercontextmenu, then allow the same function to be associated with any action using the same EventBinding.

    This way we know the function should handle the same arguments (same order, type, etc) as the original function.
    Yup, exactly. If the signatures match then we should allow.
    Aaron Conran
    @aconran
    Sencha Architect Development Team

Thread Participants: 2