Correct me if I am wrong, basically what you are wishing is having
a “resource-like” structure in the ScriptView, I think that similar to Firebug
this is not the case with URL and requests/response methods. _javascript_
developers are used to it by now, but maybe we can improve the representation
of the resources available on debugging.
Roy
From: atf-dev-bounces@xxxxxxxxxxx
[mailto:atf-dev-bounces@xxxxxxxxxxx] On Behalf Of Jacek Pospychala
Sent: Thursday, August 20, 2009 6:17 PM
To: AJAX Toolkit Framework discussion
Subject: Re: [atf-dev] accessing non-workspace resources
To follow-up on this topic,
for now I went a different way and just implemented an annotation model that
loads markers for IStorage from IWorkspaceRoot.
This is in line with wtp.sse.ui text editor so it works both in WTP HTML and
default Text editor.
Thinking more about questions 1 and 2, accessing resources via Mozilla instead
of directly by HTTP request, can be done similarly to Network Monitor. Network
Monitor already builds internal model of files loaded by Mozilla, so the model
could just be pushed down from atf.mozilla.ide.ui plugin to make it available
to ATF source locator as well.
I wonder how would it look like if mozilla resources were available eg. in
Project Explorer, eg:
/Mozilla resources
/Mozilla resources/www.eclipse.org [200]
/Mozilla resources/www.eclipse.org/style.css [304]
/Mozilla resources/www.eclipse.org/logo.png [304]
/Mozilla resources/www.google.com/analytics_code.js [304]
....
Jacek Pospychala wrote:
I should add, that there is already support for
non-workspace resources.
So far there is IStorage implemented like this:
...
Jacek Pospychala wrote:
hi there,
there's an interesting bug in ATF queue:
285596: Adding a breakpoint impossible for files outside of Eclipse workspace
https://bugs.eclipse.org/bugs/show_bug.cgi?id=285596
Most of time when debugging, we'd like to do some advanced things with
resources not in our workspace, but are identified by some URL.
For example we'd like to put there breakpoints (markers) or examine URL
content-type to open it in correct editor. From Eclipse APIs perspective this
falls under Resources API, so we'd have to make that URLs look like workspace
resources.
So here we come to questions:
1. Where should we take the resource information
a) perform HTTP requests
-> This can be risky because second HTTP request can be confusing to server
and end up failing, ot we might get different data if file is generated on the
fly.
b) query Mozilla cache/internals/API to get the file that is rendered without
any extra HTTP requests
c) any alternative?
2. When do we update resources? Because they're not in workspace, we don't get
any change notifications
a) listen to Mozilla to catch any refresh actions invoked by user and update
resources accordingly
b) everytime when accessing resource
c) any alternative?
3. How do we make non-workspace being look like workspace resources?
a) implement Eclipse File System (EFS)
b) create hidden project and cache resources there
c) any alternative?
So far, I've been experimenting with EFS and it's not very difficult to
implement some simple filesystem there, however it has rather tiny
documentation and here and there I'm finding new extra requirements. For
example, to make EFS actually work you still have to create a project in
workspace with location set to the same scheme as your virtual FS.
For now, I'm going to work on EFS approach (3a.) and try to get as much
information as possible from Mozilla (1b. and 2a.), however if anyone has any
opinions or sees better approach (e.g. other way to implement breakpoint, than
via IMarker and IResource) - pls speak up.
thanks!
Jacek
_______________________________________________
atf-dev mailing list
atf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/atf-dev
_______________________________________________
atf-dev mailing list
atf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/atf-dev
