Practical Ext JS Debugging
•Transferir como PPT, PDF•
7 gostaram•5,163 visualizações
An overview of my tactics for debugging Ext JS web applications along with some specific examples of problems I run into often, Presented at the first Three Pillar Global meeting in Fairfax, VA, on January 19, 2010. http://www.meetup.com/baltimore-dc-javascript-users/calendar/12219819/
![About Me ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Practical Ext JS Debugging
Semelhante a Practical Ext JS Debugging (20)
Último
Último (20)
Practical Ext JS Debugging
- 1. Practical Ext JS Debugging "how to waste less time"
Notas do Editor
- Were going to discuss my debugging practices that should help everyone working with JavaScript and the Ext JS library. There is no magical tool that will fix our code for us, no secret link to mystical software, but there are some tactics we can use to make sure debugging doesn't eat up our lives. Did I mention that FireBug is a requirement?
- Im your typical JavaScript loving geek.
- Before we start to dig into my debugging techniques, we need to make sure the tools of the trade are being used properly. One of these tools is the debug version of the extjs library, which includes uncompressed code, meaning line feeds are present and variable names are not cryptic. If your not familiar with this script, more information can be found on the extjs web site. Why is this important? Here I have an example of the same error first shown with the compressed version of extjs and the second with the uncompressed debug version of extjs. Notice that the variable names are short and cryptic, the line number is always 7, and the code fragment shown will always be the same. Need I say more?
- Were going to be writing thousands of lines of code for a web application, so why make it harder to understand any of that code by taking shortcuts. If were going to debug code, we need to be able to look at it and understand it. JSLint can tell us how to do this, along with making sure we dont code unintentional bugs. Make sure the code we write conforms to JSLint standards. Period. Get rid of global variables and shortcut syntax. A side effect of not conforming to JSLint standards, as shown in this first chunk of code, is that upon minification, the first chunk of code will no longer run the same as the second, since line feeds give this code its meaning.
- Now that we have the ground rules out of the way, we can actually talk about what creates errors.
- I like to place JavaScript problems into four main categories. I can almost guarantee that everything we run into will fit into one of the following four categories. Processing them in order will also decrease debugging time, increasing productivity. So what are they?
- Stupidity is the first category in my list because it can be the most frustrating, so I like to get it out of the way early. Its one of those categories of debugging that really leaves you feeling like a complete moron when you finally find the problem. This doesn't necessarily mean that you are a moron, but ill leave that up to your co-workers to decide. We could also lump misuse into this category, but im going to make the assumption that we all know how to look things up in the API. Spelling is a category that also makes you feel like an idiot, but its also a category that tends to send you in the wrong direction with its error messages. This is the fat finger category. Timing is what I like to refer to as the thinking category, because it makes us think out what our code is actually doing to be able to diagnose the problem. Scope is fairly straight forward, but often forgotten, or misunderstood. Though Its easy to figure out how to fix our code, once we know that scope is the problem. Think about those four categories, and place some of the bugs you have encountered into them. See what category comes up most often for you.
- lets go through some scenarios. If were including a file incorrectly, that's an easy one to figure out. If we decide not to check if the file has indeed been included, we could waste hours tracking down the result of this error. In the end, feeling completely stupid. If im starting to get that feeling that the changes im making in code are not taking effect, ill throw an alert into my script to make sure im working in the correct file. Now the reason I use an alert rather than a console log is to make it 100% obvious what has happend. An alert is not shy about letting you know its there, and thats exactly what I want.
- Dont overlook the obvious, it only takes a second to glance at the FireBug net tab and see that files are missing. Do it. Every time. If we dont use the tools we have available, then were not being effective at our job.
- To quote my hero Ralph Wigum - "Me fail english, thats unpossible" In the real world, there are the people that write the API and the people that use the API, and both of us not might agree about the proper case or even word to describe a particular component or event. These are things we will have to double check against the API documentation. Of course there is always the case where our fat fingers just happen to get in the way.
- The good thing, is that most of these spelling differences result in the same error. "xxx is not a constructor"
- Many of the problems in this category come from the fact that we are web developers and we tend to think of our web apps as being procedural, where you call a function, and the next line of code doesnt run until that previous call has completed. It takes some effort to overcome this thought pattern. In other words, you first code whats going to happen, then you tell it to happen.
- in standard coding you show something and then you do something else to it. In Ext JS, its very dynamic, so we want to first figure out what we need to do to this thing when its shown, then show it.
- I know every single one of you that has touched a piece of Ext JS code has dealt with scope problems. We run into the often when were interacting between different components, or telling something to wait for another to complete.
- Look to see that we haven't been stupid , if everything is spleled correctly, loading in an appropriately timed order and scoped properly.
- Im going to leave you with a final thought.... If we cannot specifically explain the problem, we have no chance of figuring out a solution on our own. Nor will anyone else be able to help. So describe the problem to yourself and work to eliminate each step. Just a little bit about one of our sponsors, JavaScript magazine, which gave us sampler issues to give to everyone .... unfortunately, the printer somehow managed to loose these somewhere in Kansas, so they did not arrive on time. If you can get your company, the company you work for, or even personally a subscription to JavaScript magazine, your really supporting the community that we all belong to, and supporting to further awareness of the JavaScript language.