Community
Participate
Working Groups
In bug 358769 we implemented a scheme for invoking commands by URL. These commands appear in the URL fragment mixed in with the "resource query parameters" that we are using in the fragment. Consider a URL such as: http://127.0.0.2:8080/navigate/table.html#/file/c/?depth=1&newFolder=foo The part after the hash is specifying the resource and some additional client parameters. The file service cares about /file/c/?depth=1 (GET /file/c/?depth=1) while the command service cares about newFolder=foo Currently we send the entire fragment to the file service, assuming any unrecognized parameters will be ignored. On the client side, we parse the parameters after the '?' and look for things we understand, ignoring others. Other approaches discussed in bug 358769 include: - anyone who interprets a parameter in the fragment should strip off that parameter before the resource gets sent to the file service - using a URI template to more formally describe the resource part of the fragment vs. the client part. See bug 358769 comment 11.
marking 0.4 for now, we need to settle on a syntax before the 0.4 release
talked to Simon Monday and he still likes: http://orion.eclipse.org/naviaget/table.html{#resource,keys*} --> http://orion.eclipse.org/naviaget/table.html#/file/c/?depth=1,newFolder=foo,a=7,b=1 Reference for UI templates: http://tools.ietf.org/html/draft-gregorio-uritemplate-07
We need to settle on this because the current support is pretty bogus. Any code that processes the hash to try to figure out what resource is being used can be easily tripped up by the command parameters. Are we ready to implement the syntax favored by Simon? If so, I can take this bug and fix up the places I know about... Some of the current problems: bogus case 1: ------------ For example, open /git/git-clone.html#/workspace/H?cloneGitRepository=bar then change the last part of the URL so that you have /git/git-clone.html#/workspace/H?cloneGitRepository=foo You'll see the git clones list reload, even the only real change was the default parameter in the slideout.. bogus case 2: ------------- /navigate/table.html#/file/BT/?depth=1&newFolder=foo then change to /navigate/table.html#/file/BT/?depth=1&newFolder=bar You'll see the nav contents reload when not necessary bogus/broken case 3: -------------- If you try to use the "newFolder=foo" command at the root, the URL doesn't have a folder, so it looks like this: /navigate/table.html#?newFolder=foo You get the slideout, but the load fails with No Matching FileService for location:?newFolder=foo (dojo.config.deferredOnError || function(x){ console.error(x); })(error);
*** This bug has been marked as a duplicate of bug 340458 ***
Reopening bug. This bug was about command invocation syntax and it still is not using the new URI templates and resource,parms. It is using resource ? parms We need to get this implemented with URI templates before 0.4 because we are going to be advertising these links. Then we'll need to update the greasemonkey scripts. The code that needs to be modified is in commands.js URLBinding.match line 1266.
There is probably associated work to do in fileClient to make sure that the template is used so that command parameters don't get sent to the server. All the cases described in this bug need to be checked.
Sorry my mistake -- thought this was adupe. Leaving it on my plate for RC1.
I have a problem with this URL: /git/git-repository.html#?cloneGitRepository=git@github.com:szbra/test.git It used to work, but now my FF reports the following problem: TypeError: invocation is undefined http://localhost:8080/orion/commands.js Line 220 Susan mentioned it may be related to this bug work.
(In reply to comment #8) > I have a problem with this URL: > /git/git-repository.html#?cloneGitRepository=git@github.com:szbra/test.git > > It used to work, but now my FF reports the following problem: > TypeError: invocation is undefined > http://localhost:8080/orion/commands.js > Line 220 > > Susan mentioned it may be related to this bug work. the typeerror in commands.js sounds like my bug. But Szymon and I were seeing cases where there were json failures coming back from the clone servlet because it was trying to parse the command parameters into something meaningful to the server.
Having just finished bug 370588, I have more to add: - somewhere in common code we need to build a URI template from the URL and change the URI template on hashchange. - then...those who normally hook hashchange to do work will use the template - for commands, this means changing commands.URLBinding.processURL - but there are many other places. Anyone who is parsing a resource name has to use the template. I just added code in settings.js but I'm sure it's all over the place. I think the key is to look for senders of dojo.hash() and places where clients hook hash change. Much of the time they are trying to get a resource name or other important piece of info from the hash. The key is to understand whether they are looking for client side parameters or a resource name and then use the new pattern (pre comma or post comma) to get the part they care about - some of these senders are trying to build parameters to send to the server, and of course these should use the resource part of the template I suspect it's scattered all over client code and I can help with this, it's really about figuring out what usage we need to search for: - dojo.hash() - hashchange - references to window.document.location - etc....
I think that for 0.4 the key part is to USE the URI template so that we can publish the #{Resource},{Parameters} pattern. Whether we specify our current command URL binding as a URI template instead is a minor point to me. The URL binding just lets the command contributor say, "this token = this command." it's an implementation detail. The part that needs to be fixed is that the URI syntax is consistent and agreed upon. So that what is now http://orion.eclipse.org/git/git-repository.html#/gitapi/clone/file/b/?cloneRepository=foo.url becomes instead http://orion.eclipse.org/git/git-repository.html#/gitapi/clone/file/b/,cloneRepository=foo.url Where there is not really a true "resource" we still have to make some determinations. For example, the URL for the new install plugin support is currently: http://orion.eclipse.org:8080/settings/settings.html#plugins?installPlugin=somePluginURL The selected settings is really a UI parameter, so one could argue that it should be http://orion.eclipse.org:8080/settings/settings.html#,category=plugins&installPlugin=somePluginURL OR if you instead considered the resource for a settings page to be the settings category you could argue for http://orion.eclipse.org:8080/settings/settings.html#plugins,installPlugin=somePluginURL
marking this bug "noteworthy" because we want our story straight before we start publishing URLs associated with the other bugs that are being fixed.
Szymon, I've posted the current fixes to the remote branch bug363960. Please could you review. Thanks.
Command bindings work well, if I have git-repo page already opened and I change just the hash to #,openGitCommit=c99e6bb41065b9ca094bce5dbafb0e2579bccf3c or similar. Then the slideout is opened. However if I paste http://host/git/git-repository.html#,openGitCommit=c99e6bb41065b9ca094bce5dbafb0e2579bccf3c to a new tab/window, the page is loaded, but there is no slideout. I'm on FF 10.0.2.
I see the same thing in Chrome. There clearly is a timing condition however I do not think it is directly related to this change and something we've uncovered. Let me dig a bit deeper.
As a project lead I +1 this change for RC3
(In reply to comment #16) > As a project lead I +1 this change for RC3 NOOO, wrong bug sorry
(In reply to comment #17) > (In reply to comment #16) > > As a project lead I +1 this change for RC3 > > NOOO, wrong bug sorry Too late ;)
The timing has changed and the command was not rendering because the toolbar had not been initialized yet. I've added a call to processURL after we're sure it is initialied and pushed the change to the branch. Szymon could you take a look again.
Greasemonkey scripts for Git work nice. Thanks Simon! There is a problem with installing plug-ins on settings.html, but Simon is on it.
I reviewed these changes in Simon's office. Approve.
Thanks All. Committed.
