1. #1
    Ext User
    Join Date
    Sep 2007
    Posts
    6
    Vote Rating
    0
    Suki is on a distinguished road

      0  

    Lightbulb Ext.log best usage?

    Ext.log best usage?


    I attempted my best to search the forums but didn't find much in the way of this topic. So here I go.

    I am a little confused at the best practice and reasoning behind the Ext.log() function. I believe it is the same at Ext.debug.log() and I was unsuccessful finding documentation on those two functions.

    Allow me to explain. The main purpose of logging (in my opinion for a web based product) would be for development and debugging. So littered through out your code is Ext.log() references. Which works excellent with the shift-control-home dialog box.

    Now here are a few annoyances I have found that makes the use of the logging too complicated to use.
    • The debug window automatically pops up the very moment the first Ext.log() is called. Then you have to hit the X. Then run your application. So you can get the the point to hit the shift-control-home combo. Very minor annoyance that I can live with. I would like to learn the reasoning behind this User Interface feature?
    • Time to roll it out to production. But including ext-all.js instead of ext-all-debug.js causes an error because Ext.log() is not defined in ext-all.js. Logically this would be desired except that now you have to go though your entire source tree removing every call to Ext.log(). A painful task. Which leads the programmer with two alternatives:
      1. The programmer drops Ext's logger for the widely implemented console.log negating the need for Ext's logger. And littering the browsers console with unneeded cruft (while in production state).
      2. Or they use it only one or two lines at a time making sure they remove the call ASAP to minimize the search and replace that comes about when it is time to roll the product out.

    This I believe is a cause for concern because every application now requires an extra step in the build process to weed out all references to Ext.log() because you want them in there for the development but removed when you minimalize the tree.

    Say you have a try statement.
    Code:
    try {
        errorProneFunction();
    }
    catch (e) {
        Ext.log(e.message);
    }
    If you remove the Ext.log() line you will never know if the errorProneFunction() threw an exception. So going back into the source after a client complained that there data was corrupted would be near imposable. Even though you were a good programmer and place the try block on there Just in case. Having an empty catch block is just bad form.

    If however you left the Ext.log() and it did nothing all you would have to do is flip one switch and your back to looking at the exception. Saving you from having to reverse the tedious search-and-replace you performed for production roll-out. Hope we're not to assuming that once an application goes production all the possible bugs have been removed.

    In contrast the YUI library implements there log function in both the debug and the production code. The difference being the the production version just immediately returns ignoring the request. This has the advantage of rolling out a production version without breaking the developer's code. And then they have the option to remove the calls later.

    The advantage to keeping Ext.log() in your production code is if a customer finds a problem you only need to change one line in the HTML code and ask them to redo the error and now you have logging. Removing the references from your code because it breaks with ext-all.js would render this technique useless.

    Thoughts / Ideas?
    (Used downloaded zip of ext-1.1.1 on firefox 2.0.0.6 / firebug 1.05, Safari 3.0.3)

  2. #2
    Sencha - Community Support Team mystix's Avatar
    Join Date
    Mar 2007
    Location
    Singapore
    Posts
    6,236
    Vote Rating
    5
    mystix will become famous soon enough

      0  

    Default


    why would you leave debugging statements in production code?

    anyhow, if you really have to, you could always deploy your code with ext-all.js, then add this line to your overrides file
    Code:
    Ext.applyIf(Ext, {
      log: Ext.emptyFn
    });
    Last edited by mystix; 3 Sep 2007 at 11:11 PM. Reason: modified code chunk

  3. #3
    Ext User
    Join Date
    Sep 2007
    Posts
    6
    Vote Rating
    0
    Suki is on a distinguished road

      0  

    Lightbulb More food for thought

    More food for thought


    Quote Originally Posted by mystix View Post
    why would you leave debugging statements in production code?
    In most cases perhaps you shouldn't leave debugging statements in production code. However that still leaves two problems. One, you have to physically weed out all the statements giving you two source trees to maintain or develop a pruning script (say PERL) similar to minification.

    The other is what do you do with your empty catch blocks? If you use try/catch to catch the mishaps you would never find them. Should the try/catch blocks be removed for consolidation reasons? Personal opinion, I guess.

    Anyway I think I'm missing something. Perhaps my development practices need to be re-thought. How do others handle logging for application information, data logging, and debugging?

    On another note: What are some of the advantages to using a debugging logger like Ext.log vs alerts vs a debugger (FireBug) vs console.log?

  4. #4
    Sencha - Community Support Team mystix's Avatar
    Join Date
    Mar 2007
    Location
    Singapore
    Posts
    6,236
    Vote Rating
    5
    mystix will become famous soon enough

      0  

    Default


    did you try that chunk of code i gave you?

    you can leave all your Ext.log statements intact in your deployment code if you want to.
    just deploy with ext-all.js and that chunk of code to define Ext.log as the empty function (if Ext.log doesn't already exist).

    then, if you need to switch to debug mode, just switch to ext-all-debug.js.

  5. #5
    Ext User
    Join Date
    Sep 2007
    Posts
    6
    Vote Rating
    0
    Suki is on a distinguished road

      0  

    Default


    The code works fine. I was just asking the above for thoughts on the subject. I am interested in hearing how people perceive good coding practices and why.

    Thank you for the code snipit I will use that if I need to.

  6. #6
    Ext User
    Join Date
    Sep 2007
    Posts
    2
    Vote Rating
    0
    MichelvdL is on a distinguished road

      0  

    Default Logging is useful even for non-debug issues

    Logging is useful even for non-debug issues


    I think the YAHOO logger is incredibly useful, even for non-debug type functionality. I recently started playing with ext and it seems an improvement over yui, but I really miss the logger. The ability to classify, log, filter and track events is useful even for production code.

  7. #7
    Sencha - Community Support Team mystix's Avatar
    Join Date
    Mar 2007
    Location
    Singapore
    Posts
    6,236
    Vote Rating
    5
    mystix will become famous soon enough

      0  

    Default


    the YUI logger sounds like a good candidate for conversion to an Ext.ux...
    (though i don't see a need to at this point since there's trusty Firebug by most of our sides)

    in the meantime though, have you checked these out?
    http://extjs.com/deploy/ext/docs/out...rvable.capture
    http://extjs.com/deploy/ext/docs/out...releaseCapture

    and here's some sample code on how to use those thingies above
    Code:
    Ext.onReady(function() {
      // create something to observe
      var converted = new Ext.form.ComboBox({
        typeAhead: true,
        triggerAction: 'all',
        transform: 'test',
        width: 135,
        forceSelection: false
      });
      
      // observe that thing
      Ext.util.Observable.capture(converted, function() {
        console.log("event '" + arguments[0] + "' was fired with the following arguments: ");
        for (var i = 1; i < arguments.length; i++) {
          console.log("        [" + i + "] ", arguments[i]);
        }
      });
    });
    you'll need to have Firebug installed.

  8. #8
    Ext User
    Join Date
    Sep 2007
    Posts
    2
    Vote Rating
    0
    MichelvdL is on a distinguished road

      0  

    Default Logging, bugs, firebug, etc.

    Logging, bugs, firebug, etc.


    I have firebug, it's a fantastic tool. Having said that, the folks looking at my applications use IE. No firebug there. And even if there was, I'd really hate to talk them through getting information out of that!

    The fact is, most of my code has bugs, even after acceptance testing, load testing, code review, etc. I've spend lot's of time in my life reviewing, debugging and fixing other people's code, and in my experience the most useful thing to know is, what was the last thing that worked successfully, and when was the first time something went wrong.

    Having the logger type functionality, allowing me to keep a trail (hopefully limited in size) of events that I, as a developer, know are important to the application, that can be easily captured by a consumer of my application, for my review when we find a bug (or failing web-service, or failing DNS, or whatever else may go wrong) is pretty useful.

    Thanks for the suggestions though!

  9. #9
    Ext User
    Join Date
    Sep 2007
    Posts
    6
    Vote Rating
    0
    Suki is on a distinguished road

      0  

    Wink


    Quote Originally Posted by MichelvdL View Post
    The fact is, most of my code has bugs, even after acceptance testing, load testing, code review, etc. I've spend lot's of time in my life reviewing, debugging and fixing other people's code, and in my experience the most useful thing to know is, what was the last thing that worked successfully, and when was the first time something went wrong.
    Yes yes this is exactly the concept I was wondering about. Now granted the Ext.log() does not provide levels of logging (info, error, warning, debug, etc) like YUI does. Which is too bad. But what is worse is if you do use logging to monitor the progress of your code then once you roll it out to your production code you have to manually (Or with a painful script) remove the references to Ext.log() and all the logic involved with them. Or as mention above assign Ext.log() to a null function. Which is what I'll do since commenting two lines of code in the file is better then search and replacing the entire source tree.

    Perhaps a mention in the docs that if you use a logger to monitor the progress of your application you must create a null function reference to the Ext.log() function when you remove the -debug from the script call otherwise your application will break.

  10. #10
    Ext User
    Join Date
    Sep 2007
    Posts
    6
    Vote Rating
    0
    Suki is on a distinguished road

      0  

    Thumbs up


    Quote Originally Posted by mystix
    in the meantime though, have you checked these out?
    http://extjs.com/deploy/ext/docs/out...rvable.capture
    http://extjs.com/deploy/ext/docs/out...releaseCapture

    and here's some sample code on how to use those thingies above
    Oh Wow now that is cool. Perhaps a wrapper function and a bit of reflection would make this very nice. and with a good minification script would weed out block that cannot be reached. Like so:

    Code:
        // observe that thing
    if (Ext.log) {
      Ext.util.Observable.capture(converted, function() {
        Ext.log("event '" + arguments[0] + "' was fired with the following arguments: ");
        for (var i = 1; i < arguments.length; i++) {
          Ext.log("        [" + i + "] ", arguments[i]);
        }
      });
    }
    Now how do we stop the debug window from showing up every time the Ext.log() function fires off. I think I have a few good ideas though. I'll look into to maybe extending Ext.log you know as a experiment for the user sort of thing.

    Thank you every one for your very insightful feedback.
    Last edited by Suki; 4 Sep 2007 at 9:54 AM. Reason: Missed quote reference

Turkiyenin en sevilen filmlerinin yer aldigi xnxx internet sitemiz olan ve porn sex tarzi bir site olan mobil porno izle sitemiz gercekten dillere destan bir durumda herkesin sevdigi bir site olarak tarihe gececege benziyor. Sitenin en belirgin ozelliklerinden birisi de Turkiyede gercekten kaliteli ve muntazam, duzenli porno izle siteleri olmamasidir. Bu yuzden iste. Ayrica en net goruntu kalitesine sahip adresinde yayinlanmaktadir. Mesela diğer sitelerimizden bahsedecek olursak, en iyi hd porno video arşivine sahip bir siteyiz. "The Best anal porn videos and slut anus, big asses movies set..." hd porno faketaxi