[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [orion-dev] Client side integration options
|
On 1/19/2011 8:08 AM, Boris Bokowski wrote:
Hi John,
See my comments/answers below...
John J. Barton wrote on 2011/01/19 10:25:28:
> Suppose I have a browser-based Web debugger: how can I use Orion to
edit
> source based on links available in the browser?
There's a related question of how we can synchronize breakpoints and
potentially other debugging-related information, but it's a good idea
to focus on editing first.
Yes, because the information exchange we need to launch edit is tiny and
we get a large benefit.
> > Based on what I have been able to discover so far, Orion serves
from the
> file system, rewriting the base of the file name with an http url.
Yes, that is how the Orion server works at this point. I could imagine
it editing files that are not in the file system. It could
We can do that with data URLs or with direct integration of the editor
source into the debugger without a server. But my immediate interest is
files in the file system.
also be the case that the URLs known to the browser (and the debugger)
are different than the URLs used for editing the files, for example if
you are using a build, or some kind of server-side templating mechanism.
Well that's pretty much always the case for Orion right? You never serve
a file with the editor URL. The mapping may be simple as different bases
or hard as we like.
> So one path is have a URL rewriter on the debugger side, that break off
> the browser's base URL and prefixes Orion's:
This would work today, but as you point out it would have to be
configured by developers, probably for every project. Also, the URL
rewriter could become very complex, if we wanted it to cover cases
like builds (concatenated and/or minified files).
I'm sure someone will want to work on those cases ;-)
> Another path is to attach an editor URL to served files. That's a fine
> solution in the long run, but it means getting servers to agree.
Don't you think it would be possible to get servers to agree eventually?
Unfortunately there is a three way problem here: server, editor-server,
browser. So it's not enough to get editor-server and browser tools to agree.
Someone would have to start using this approach, and Firebug is in a
good position to be that "someone" ;-)
Let's try...
> Another could be a top-level Orion URL for looking up files, eg
> http://localhost:8080/findFile?path=content/firebug/external/
> changewebeditor.js&
This also would mean that servers would have to agree. I am not sure
which solution I like better, my gut feeling would be to avoid
solutions that rely on URL manipulation. On the other hand, a
top-level URL might be easier to do for existing servers that are hard
to change.
Ok a variation:
If Firebug sees an http header
x-edit-token:
it will string trim it an issue
http://localhost:8080/findFile?editToken=<opaque>&
The server can use a URL encoded file URL for the token if it likes, or
it can hash the name if the security folks are watching.
Else if Firebug thinks it knows the local file, it issues
http://localhost:8080/findFile?localFile=<encodedFileURL>&
In all cases the server redirects to the code.html URL (or whatever you
like).
> Other ideas?
Not really. I am eager to make progress though. Let me know if I
should add something to Orion to enable experimentation in Firebug!
Well I can do the remapping thingy now and if you want to try the
findFile thing let me know.
Boris
