17 Jul 05:39
Would like a better idea of how javascript debugging is meant to work with templates (e.g. erb/rhtml)
From: Anthony Richardson <list.netbeans@...>
Subject: Would like a better idea of how javascript debugging is meant to work with templates (e.g. erb/rhtml)
Newsgroups: gmane.comp.java.netbeans.modules.ruby.devel
Date: 2008-07-17 03:42:27 GMT
Expires: This article expires on 2008-07-31
Subject: Would like a better idea of how javascript debugging is meant to work with templates (e.g. erb/rhtml)
Newsgroups: gmane.comp.java.netbeans.modules.ruby.devel
Date: 2008-07-17 03:42:27 GMT
Expires: This article expires on 2008-07-31
Cross posted to nbajax-gVrGfPuBK2Jg9hUCZPvPmw@public.gmane.org and dev-n3CzLFQkLgrXWKka9uoeGti2O/JbrIOy@public.gmane.org
I wanted to get an idea of what the expected level of functionality the javascript debugger is going to be capable of offering when debugging web pages generated from templates.
I'm using Ruby on Rails and all responses returned to the browser are constructed from erb files (although other templating systems are also available). Basically a erb file is a normal HTML file with support for embedded ruby code. Rails constructs the responses by merging many erb files to create the resulting response to the user. Often the same erb file is called many times with different parameters for constructing things like lists etc..
Is it expected that developers will be able to place breakpoints in these erb files in any location and have the debugger resolve the locations of the many source files that may have contributed to the resulting page the user is currently viewing? (I'm not sure that this is even possible without injecting debugging specific markup into the served page as the page construction is a lossy process like compilation).
I have experimented with setting break points in a default Rails application and the results are less than stellar. I can't get the javascript debugger to reliably stop at a breakpoint in a erb file. I can get it to work well for static HTML files if I use the full url e.g. localhost:3000/index.html rather than localhost:3000. I can also get breakpoints working with included JS files, but only if they don't have parameters(isses #140442)
In the past I have got the debugger to stop at some breakpoints in a rhtml file that was a single rhtml with no layouts or partials (not the Rails default way of doing things). But the debugging features were broken after it has stopped and there was nothing you could do except cancel the debugging session. I haven't been able to repeat this limited success with later builds and using erb files.
I'm not privy to how the javascript debugger works, but from the little bits I have gleamed I think it does some sort of matching the URL to the files on disk. I can't see how this is going to work with Rails as this link is tenuous at best. Especially when using restful routing (the default and preferred method) with nested resources. The generated URL do not match the file system structure at all.
e.g.
localhost:3000/people/1/
I wanted to get an idea of what the expected level of functionality the javascript debugger is going to be capable of offering when debugging web pages generated from templates.
I'm using Ruby on Rails and all responses returned to the browser are constructed from erb files (although other templating systems are also available). Basically a erb file is a normal HTML file with support for embedded ruby code. Rails constructs the responses by merging many erb files to create the resulting response to the user. Often the same erb file is called many times with different parameters for constructing things like lists etc..
Is it expected that developers will be able to place breakpoints in these erb files in any location and have the debugger resolve the locations of the many source files that may have contributed to the resulting page the user is currently viewing? (I'm not sure that this is even possible without injecting debugging specific markup into the served page as the page construction is a lossy process like compilation).
I have experimented with setting break points in a default Rails application and the results are less than stellar. I can't get the javascript debugger to reliably stop at a breakpoint in a erb file. I can get it to work well for static HTML files if I use the full url e.g. localhost:3000/index.html rather than localhost:3000. I can also get breakpoints working with included JS files, but only if they don't have parameters(isses #140442)
In the past I have got the debugger to stop at some breakpoints in a rhtml file that was a single rhtml with no layouts or partials (not the Rails default way of doing things). But the debugging features were broken after it has stopped and there was nothing you could do except cancel the debugging session. I haven't been able to repeat this limited success with later builds and using erb files.
I'm not privy to how the javascript debugger works, but from the little bits I have gleamed I think it does some sort of matching the URL to the files on disk. I can't see how this is going to work with Rails as this link is tenuous at best. Especially when using restful routing (the default and preferred method) with nested resources. The generated URL do not match the file system structure at all.
e.g.
localhost:3000/people/1/
addresses would call the AddressController and load the view /app/views/addresses/index.html.erb by default. Rails knows to pull apart the URL and supply the person ID of 1 as a parameter to the addresses controller.
Some guidance on what level of support/behaviour you guys are aiming at would be very helpful.
Cheers,
Anthony Richardson
Some guidance on what level of support/behaviour you guys are aiming at would be very helpful.
Cheers,
Anthony Richardson
RSS Feed