[CLOSED] Discrepancies in JavaScript function signatures

  1. #1

    [CLOSED] Discrepancies in JavaScript function signatures

    There seems to be some discrepancies on the function signatures that are shown (arguments list) between your:
    AND
    Your 4.2.2 Examples Source code https://examples4.ext.net/


    Below are some examples that I have come across during our upgrade project (1.2 to 4.2.2)
    (I am following your samples source code since it seems to more accurately reflect the argument names for these functions)

    DataView -> ItemClick
    Your Listeners/Arguments Utility shows function signature as:
    DataView ->  ItemClick  =  function ( item, record, node, index, e )
    Your Samples Code shows a more accurate arguments list:
    https://examples4.ext.net/#/DataView/Advanced/Grouping/
    https://examples4.ext.net/#/DataView/Advanced/Report/
    <script>
      var itemClick = function (view, record, item, index, e) {  }
    	  	  
      <ext:DataView
    	<Listeners>
    		<ItemClick Fn="itemClick" />
    		<Refresh Handler="this.el.select('.item-wrap', true).addClsOnOver('x-view-over');" Delay="100" />
    	</Listeners>


    TreePanel -> ItemContextMenu
    Your Listeners/Arguments Utility shows function signature as:
    TreePanel ->  ItemContextMenu =  function ( item, record, node, index, e )
    Your Samples Code shows a more accurate arguments list:
    https://examples4.ext.net/#/TreePane...d/Remote_Mode/
    <script>
    <script>
    	var showMenu = function (view, node, item, index, e) {
    
    <ext:TreePanel>
    	<Listeners>
    		<ItemContextMenu Fn="showMenu" StopEvent="true" />
    		<RemoteActionRefusal Handler="Ext.Msg.alert('Action refusal', e.message);" />
    	</Listeners>

    There a lot more than just these two examples.

    NOTE: When in a script debugger breakpoint I can see in the call-stack what seems to be a generic '*fire'" function that shows the same arguments as the Listeners Utility - but the Source Code samples that I find seem to sometimes transpose the names of the arguments to more correctly align with the actual parameter content.

    Problem is that the source code samples do not encompass all of the different function listeners for most of the components - so if I cannot find it in the source code samples (correctly aligned), I have to follow the Utility's given signature. But, to reiterate, I am finding in some instances how the argument name does not always truly corresponds with the actual contents of the argument.

    Any advise on this would be appreciated.

    Rafaelcjr now posting under Advance Loan Tech.
    Last edited by fabricio.murta; Jul 17, 2017 at 4:52 PM.
  2. #2
    Hello @RafaelCjr!

    I don't think there's really a problem on that. Except when you are using Handler= on your events.

    For example, in the code bit you show:

    <ItemClick Fn="itemClick" />
    <Refresh Handler="this.el.select('.item-wrap', true).addClsOnOver('x-view-over');" Delay="100" />
    For the Item Click case, as long as you know it takes 5 arguments (function ( item, record, node, index, e )), you may name them after whatever you like in the handler... in other words, this would have worked just the same:

    var ItemClick = function (a, b, c, d, e) {
        var myRecord = a,
            myNode = c,
            idx = d;
    };
    In fact, if you need just, say, the item and node, you could do just:

    var ItemClick = function (item, b, node) {
        var sourceView = item,
            affectedNode = node;
    };
    Now the problem lies on the second line (although not explored in the example you shown). There you have:

    <Refresh Handler="this.el.select('.item-wrap', true).addClsOnOver('x-view-over');" Delay="100" />
    Right. If you go to the utility and query for the Refresh list of arguments, you'd get this:

    function ( item )
    Alright, simple, single parameter. But the important thing is: if you want to reference the parameter in a Handler= quick-line, you then must obey the nomenclature shown in the utility. You can't assume the first argument is either view nor a like you can do when you use Fn=.

    In fact, the Refresh line could have been rewritten as:

    <Refresh Handler="item.el.select('.item-wrap', true).addClsOnOver('x-view-over');" Delay="100" />
    Just by coincidence, usually the first argument to the listeners is exactly the value of this.

    So summarizing:
    - when you use a component listener's Fn= binding, you have the freedom to name the event parameters after whatever you feel like.
    - if you are going to use the listener's Handler= property, then you must obey the prototype shown by the signature.

    The reason for that is because when you do Refresh Handler="my_code_here" Ext.NET outputs that like

    listeners: {
        refresh: function(item) {
            my_code_here;
        }
    }
    Being line 2 above according to what you see in the examples explorer's utility.

    While we try to keep these signatures in sync with ExtJS documentation, this may not be the case all the times, and the most accurate information would come our utility. Again, it is only important when you use the Handler= property. We don't really focus the examples on keeping the argument names matching ExtJS's as that's not really necessary.

    I hope this clarifies your questions regarding the matter, sorry if that made it confuse for you!
    Fabrício Murta
    Developer & Support Expert
  3. #3
    Fabricio

    Thank you for the detailed response.
    Yes, I am painfully aware how in general software engineering you can call your function arguments whatever you like - especially in scripting languages (30yrs of fixing/debugging other people's code).

    You did answer the question I had (about the discrepancies I saw) -
    "While we try to keep these signatures in sync with ExtJS documentation, this may not be the case..."

    I know that I can "trust" your Arguments Utility to give me the correct NUMBER of arguments,
    and MOST/SOME of the time, the argument NAMES assigned match the contents of those arguments.

    This question came about when I was trying to advise other developers here when, for example:
    a "node" argument in a handler did not contain ".childNodes" collection or ".data" obj property
    (and similar issues)

    I just needed the confirmation from you guys, so that I can help the developers on this project write maintainable/readable code as we upgrade forward.

    Thanks again


    P.S.
    You mentioned in a previous post the difficulty of searching all of the ChangeLogs & BreakingChange Logs from v1 to v4
    I have attached a file that I compiled that we are using (notepad++) to quickly do that.
    This might help other people in this forum. (had to Zip it change its extension to txt (is too big) hopefully i did not break forum rules)

    FULL ChangeLogs EXT.Net.zip.txt
  4. #4
    Hello @AdvanceLoanTechnologies!

    While you're paying attention to these events' signatures, you may want to let us know in the case ours (the tool's) version does not match Sencha's signatures. Some may slip our grasp when performing upgrades (and in special when Sencha's changelog does not mention the change).

    Well, another problem of that kind of change is introducing breaking changes into minor versions.

    If you use a Handler="items.id" on 4.2.2 and in 4.2.3 it becomes view (in the case of Refresh above), forcing everyone to change this to Handler="view.id", that would be something we would rather not follow Sencha change until a major release, for the sake of overall system compatibility between minor versions.

    We do our best to avoid breaking changes whereas ExtJS usually brings breaking changes without a second thought (they for sure have their reasons, let's not argue about it). Sometimes we even patch ExtJS to keep backwards compatibility (and leave a note to remove the patch on our next major release).

    About the attached file, we don't usually accept this kind of file but I personally believe on your good will sharing it, and agree it could be useful for other users, being aware the file is provided as-is, is not official and was not reviewed by Ext.NET team, so the disclaimer "use at your own risk". :)

    When you have a suggestion or an example/contribution you want to share, we have the Examples and Extras forum you could use. As the forums gets indexed by google, it would become a great way for searching Ext.NET related content.

    On a second thought... Did that 'node' argument you used as example bug you at all? I mean, does it exist on two events having different actual values? Javascript gives a lot of freedom, and sometimes it may come as a problem. Besides, many arguments in ExtJS accept different types. For example, sometimes you can provide the ID of a component instead of the component itself and ExtJS does the job of turning the ID into the component for you. So, the same method would handle a string or a component object.
    Fabrício Murta
    Developer & Support Expert
  5. #5
    Hello @AdvanceLoanTechnologies!

    It's been a while since we last posted here and still no feedback from you. Do you still need help on this issue or may we mark the thread as closed? This thread may be compulsorily marked as closed if you don't provide a feedback here in 7+ days from now. But no matter what, you will be able to post back here whenever you feel like.
    Fabrício Murta
    Developer & Support Expert
  6. #6
    Desculpa Fabricio,

    Yes, you guys can mark this as closed. (This upgrade from v1.2 to v4.2 can get kind of hectic, I did not keep up with the forum)

    In response to the last suggestions/questions:

    "When you have a suggestion or an example/contribution you want to share, we have the Examples and Extras forum..."
    I created a post for that Text file Change Log compilation in your other forum
    https://forums.ext.net/showthread.ph...eaking-Changes

    "Did that 'node' argument you used as example bug you at all?"
    The specific problem with the node argument was me trying to help another developer that mentioned to me that he could not retrieve childnodes from the node variable (I knew this was not right since I has worked on another page with a treepanel and could see the childnodes in script) - I decided to create this post to elucidate this issue (handler argument names might not reflect contents) so that the other developers on this project understood the issue - with the explanation coming from you guys.


    I usually do not encounter these problems, because I normally 'clean up" the original/old code by changing any complex 'Handler's (inline scripts) to 'Fn' (function) - this way I can name my arguments to reflect their correct names (and also consolidate a lot of 'nasty cut and paste' handler script code I encounter)
  7. #7
    Hello @Rafaelcjr!

    Glad it is sorted out, and thanks for your thoughtful feedback, we really appreciate it!
    Fabrício Murta
    Developer & Support Expert

Similar Threads

  1. [CLOSED] Get javascript function's value
    By multimediait in forum 2.x Legacy Premium Help
    Replies: 6
    Last Post: Oct 24, 2014, 10:20 AM
  2. Calling JavaScript function
    By UserClarion in forum 1.x Help
    Replies: 2
    Last Post: Dec 30, 2011, 10:23 AM
  3. Replies: 1
    Last Post: May 14, 2011, 3:52 PM
  4. How i can html of tooltip in javascript function
    By vucuongkg in forum 1.x Help
    Replies: 1
    Last Post: Jun 17, 2010, 4:05 PM
  5. [CLOSED] The javascript function in not fire?
    By Etisbew in forum 1.x Legacy Premium Help
    Replies: 7
    Last Post: Sep 09, 2009, 10:12 AM

Tags for this Thread

Posting Permissions