Anthony Richardson wrote:
> Cross posted to
nbajax@... <mailto:
nbajax@...> and
>
dev@... <mailto:
dev@...>
>
> 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 webpages 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).
In 6.5 it is only possible to set the breakpoints in html and javascript
files as long as the URL as seen by the browser can be mapped to the
file in the project by simple lookup of the path part of the URL
relative to the source roots in the project. You will be able to set the
breakpoints in the HTML that the browser sees in terms of URL. To load
this html you need to go to the Windows:Debugging:Sources window, select
the URL and use "Go to Source" action to load it in the editor tab - the
editor tab title will show the
http:///..../ like name (tooltip will
show the full name). This of course is a read-only editor. You should be
able to use features like:
- set breakpoint
- hover caret over an identifier or a selection to show the values in
tooltip when the debugger is suspended (breakpoint, debugger keyword or
while stepping)
- create watches from selection
>
> 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.
This particular issue has now been fixed. localhost:3000 is now
automatically mapped to public/index.html
> I can also get breakpoints working with included JS files, but only if
> they don't have parameters(isses #140442)
See above.
>
> 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.
The breakpoints in RHTML file are server side breakpoints. To debug
RHTML files you will have to use the technique described above.
>
> 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.
Yes. RIght now it is a very simple mappping - only for html and
javascript files. This is because the line number mapping is identical.
> 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.
We will implement more sophisticated mapping in future releases.
>
> Some guidance on what level of support/behaviour you guys are aiming
> at would be very helpful.
>
Regards,
Sandip
---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@...
For additional commands, e-mail:
dev-help@...
