Yea, sure, that can end up being pretty convoluted. I just use it at the
point I've narrowed an issue down to a particular area. I add in the anon
function call, do the debugging, and delete it when I'm done.
On 6/20/07, Dave Crane <[EMAIL PROTECTED]> wrote:
>
>
> Hi Ryan,
>
> Oh well, that's a shame, I was hoping to be proven wrong on this one :)
>
> I like the AnonymousDebug() function - lets you add the breakpoints
> without
> having to add debugger; statements into the code. But in a complex script,
> wouldn't you need several of these to avoid the breakpoint getting
> triggered
> whenever _anything_ happens, if you have lots of calls to it peppeed
> through
> the code. And if you need to uncomment the calls to the anon debug fn,
> you're
> back to writing "debugger;" statements.
>
> I'll give it a try anyway, and see what it feels like in practice.
>
> Cheers,
>
> Dave
>
> On Thursday 21 June 2007 15:37, Ryan Gahl wrote:
> > Very real concerns, Dave. Yep, I code js the same way, and use anonymous
> > functions all over the place. There are some places where you're right,
> you
> > need a debug anchor to make a deep function line breakable. The standard
> > way of defining method, as you describe, though works fine in VWD. So
> yes,
> > I've learned to live with the fact that if I want to step through some
> > functions, I need to place a debug anchor method call at the
> beginning...
> >
> > For example:
> >
> > test = Class.create();
> > test.prototype = {
> > initialize: function() {
> > //lines in here are breakpoint enabled
> > },
> >
> > test: function() {
> > //same with this function
> > },
> >
> > test2: function() {
> > var someArray = [1,2,3,4,5];
> > someArray.each(function(num) {
> > //trying to place a breakpoint in here results in the script
> > breaking no within the anonymous function, but at the point the .each()
> > method is called
> > });
> > }
> > }
> >
> >
> > So, the way to be able to step through those types of functions is to
> have
> > some generic empty method at a higher level (global is fine), place a
> > breakpoint within it, then call that function from within the anonymous
> > function you want to step through...
> >
> > function AnonymousDebug() {
> > //place breakpoint on this line
> > }
> >
> > ...within test2() from the example above...
> > someArray.each(function(num) {
> > AnonymousDebug();
> > //when it breaks within that anchor function, you can then hit
> F11
> > to step into this function
> > });
> >
> >
> > So, as mentioned, 'tis not ideal, but you can workaround things. As I
> > understand, the script debugging facilities shipping with the next
> version
> > ("Orcas") handles anonymous debugging much better.
> >
> > The question was, "what's the best tool available for free to debug js
> in
> > IE".... VWD is it, and this is how... :-)
> >
> > Oh, also, while debugging, in VWD you can go to "Debug > Windows >
> Script
> > Explorer" to see the list of currently loaded script, including eval'ed
> > code, which you can use to place breakpoints in and step through, which
> is
> > something firebug doesn't let you do. So, right now, it's a trade off
> for
> > sure.
> >
> > On 6/20/07, Dave Crane <[EMAIL PROTECTED]> wrote:
> > > Hi Ryan,
> > >
> > > Good point - I've seen the express vis studio editions, didn't make
> the
> > > connection. It's a pretty big download/install for a debugger, but
> hard
> > > disks
> > > and bandwidth are cheap these days, I guess!
> > >
> > > I'm currently using the Script Editor that comes with FrontPage 2003
> > > (same thing that ships with VS 2003, I think? I hasten to add that I
> > > don't use Front Page for anything else, it's just the cheapest route
> to
> > > getting the script editor that I knew of!).
> > >
> > > Anyway, the one thing that really limits script editor's usefulness to
> me
> > > (and
> > > the freebie debugger is the same in this respect) is that the
> > > breakpoint-setter doesn't understand inline function definitions, e.g.
> > >
> > > 01 function blah(){
> > > 02 new Ajax.Request(
> > > 03 myURL,
> > > 04 { method: "POST",
> > > 05 onComplete:function(xhr){
> > > 06 var responseObj=Object.toJSON(xher.responseText);
> > > 07 doSomething(responseObj.this);
> > > 08 doSomethingElse(responseObj.that);
> > > 09 }
> > > 10 }
> > > 11 );
> > > 12 }
> > >
> > > stopping me from setting breakpoints on lines 6-8 interactively,
> which,
> > > in an
> > > Ajax app, is usually where a lot of the interesting stuff is going on.
> > > Worse,
> > > when I define a JS object type using Class.create() and the
> > > MyObjectType.prototype={ } approach, every method of the object is an
> > > inline
> > > function declaration, hence inaccessible to the debugger's breakpoint
> > > mechanism. The whole P&S coding style is geared around inline
> functions,
> > > and
> > > not for trivial, stylistic reasons either. That functional-style
> > > programming
> > > approach has a very natural fit to JS as a language, and I'd be loath
> to
> > > give
> > > it up these days.
> > >
> > > I can add a "debugger;" statement to my code within lines 6-8 and
> reload
> > > the
> > > app, but that's kind of tedious and defeats the immediacy of the
> > > interactive
> > > debugger. I could also stop defining functions inline, and pass
> > > references to
> > > top-level functions, but that would make my code look like death
> warmed
> > > up.
> > >
> > > OK, this is starting to sound like a rant - I'm not venting my spleen
> at
> > > you,
> > > Ryan. You've got the VWD installed already, and say you like it. Does
> > > the VWD debugger understand inline function declarations in the way
> I've
> > > described (a basic prerequisite for being 'capable' IMO)? If so, I'll
> > > happily
> > > burden my machine with it's 300MB presence and abstain from saying
> rude
> > > things about MS tools for, ooh, a whole day at least.
> > >
> > > TIA
> > >
> > > Dave Crane
> > >
> > > On Wednesday 20 June 2007 15:02, Ryan Gahl wrote:
> > > > You can get VWD (Visual Web Developer) Express from MS for free,
> which
> > >
> > > is
> > >
> > > > basically VS pared down. That has excellent js debugging. Yes, I use
> > > > firebug all the time, and love it. But yes, the js bebugging in VWD
> is
> > >
> > > far
> > >
> > > > faster and more capable. I use firebug for FF dev, VWD for IE dev.
> > >
> > > --
> > > Author: Prototype & Scriptaculous in Action, Ajax in Practice, Ajax in
> > > Action
>
> --
> Author: Prototype & Scriptaculous in Action, Ajax in Practice, Ajax in
> Action
>
> >
>
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
Architect
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-262-951-6727
Blog: http://www.someElement.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Spinoffs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
