Community
Participate
Working Groups
I20111116 Susan just released support to open the Git repository page, pre-populated with a slide-out for cloning a repository. For example: http://localhost:8080/git/git-clone.html#/workspace/A?cloneGitRepository=ssh://git.eclipse.org/gitroot/orion/org.eclipse.orion.client.git However, notice this this includes /workspace/A. For another user that will be different. Ideally I could give someone a URL like this: http://localhost:8080/git/git-clone.html#?cloneGitRepository=ssh://git.eclipse.org/gitroot/orion/org.eclipse.orion.client.git I noticed if I enter the following: http://localhost:8080/git/git-clone.html It automatically appends the workspace URI in the hash. So, we need to either: 1) Remove the workspace URI from the hash on the git clone page. 2) Do the same redirect in the case where the cloneGitRepository command is present in the hash
iirc the workspace URI is there to indicate from which workspace the repos are listed. Is there a default workspace that can be used in case the URI is not there?
(In reply to comment #1) > iirc the workspace URI is there to indicate from which workspace the repos are > listed. Is there a default workspace that can be used in case the URI is not > there? If I don't provide a workspace URL at all it works: http://localhost:8080/git/git-clone.html I'm just suggesting we do the same thing in the case where a hash is present. If we moved to support multiple workspaces we would need to rethink what this page means (does it show all repos for the user, or all repos in a given workspace?)
(In reply to comment #0) > 1) Remove the workspace URI from the hash on the git clone page. > 2) Do the same redirect in the case where the cloneGitRepository command is > present in the hash I would go with the latter, but first I need to get my head around what's going on in git-clone.js and git-clones-explorer.js.
(In reply to comment #0) > Ideally I could give someone a URL like this: > > http://localhost:8080/git/git-clone.html#?cloneGitRepository=ssh://git.eclipse.org/gitroot/orion/org.eclipse.orion.client.git If you remove the # from the URL it works like a charm. The workspace URI is appended, and the result looks like this: http://localhost:8080/git/git-clone.html?cloneGitRepository=ssh://git.eclipse.org/gitroot/orion/org.eclipse.orion.client.git#/workspace/P After a chat with Gosia, we agreed that having the cloneGitRepository param there is actually a better way of augmenting the Git Repos page behavior. The param is for the UI (git-clone.html) not the resource (/workspace/P). A minor issue I noticed was the fact that once #/workspace/P is added and you refresh the page (or open a new tab for the link with workspace part), the slide-out doesn't show up. Susan, any tips where I should look to fix this?
(In reply to comment #4) > (In reply to comment #0) > > Ideally I could give someone a URL like this: > > > > http://localhost:8080/git/git-clone.html#?cloneGitRepository=ssh://git.eclipse.org/gitroot/orion/org.eclipse.orion.client.git > > If you remove the # from the URL it works like a charm. The workspace URI is > appended, and the result looks like this: > > http://localhost:8080/git/git-clone.html?cloneGitRepository=ssh://git.eclipse.org/gitroot/orion/org.eclipse.orion.client.git#/workspace/P > > After a chat with Gosia, we agreed that having the cloneGitRepository param > there is actually a better way of augmenting the Git Repos page behavior. The > param is for the UI (git-clone.html) not the resource (/workspace/P). Not sure this is right. A true query parameter is something the server interprets, and in general everything in the fragment is considered client-side concern. But I defer to the experts. Simon wants a URI template that would use something like http://orion.eclipse.org/naviaget/table.html{#resource,keys*} so we'd have something like: http://localhost:8080/git/git-clone.html#/workspace/P,cloneGitRepository=ssh://git.eclipse.org/gitroot/orion/org.eclipse.orion.client.git This would separate the stuff we send via GET from what the UI looks for. Please see bug 363960 and bug > > A minor issue I noticed was the fact that once #/workspace/P is added and you > refresh the page (or open a new tab for the link with workspace part), the > slide-out doesn't show up. Susan, any tips where I should look to fix this? The parsing currently is looking in the fragment, so if you are changing the URL format, we need to tweak commands.js, CommandService.processURL I'd like to settle bug 363960 though... The par
(Sorry, I accidentally that last comment before I finished editing it.) Simon, you had proposed a pattern like http://orion.eclipse.org/naviaget/table.html{#resource,keys*} but in the clone scenario, we don't want to specify a resource because we can infer the workspace from the user. So what would the git clone URI look like? Just skip the resource part? http://localhost:8080/git/git-clone.html#,cloneGitRepository=ssh://git.eclipse.org/gitroot/orion/org.eclipse.orion.client.git Or is there some kind of placeholder for the resource part after the hash?
(In reply to comment #6) > Simon, you had proposed a pattern like > http://orion.eclipse.org/naviaget/table.html{#resource,keys*} Will dojo.hash() know how to handle it? In most places we get and set the dojo.hash to get the resource address. In this case "cloneGitRepository=ssh://git.eclipse.org/gitroot/orion/org.eclipse.orion.client.git" changes the client page (opens the clone window) so adding is as a parameter of js page would be more accurate that adding it somewhere in the resource area (after the hash).
(In reply to comment #7) > Will dojo.hash() know how to handle it? In most places we get and set the > dojo.hash to get the resource address. We would need to handle this ourselves in our client code that uses dojo.hash. > In this case > "cloneGitRepository=ssh://git.eclipse.org/gitroot/orion/org.eclipse.orion.client.git" > changes the client page (opens the clone window) so adding is as a parameter of > js page would be more accurate that adding it somewhere in the resource area > (after the hash). It's true that the command is more related to the page than the resource. But the root issue is this is a client side concern. The server doesn't send us back a different version of the page that has the slide-out open. We get the static page back, and then use client side code to open the slide-out. Changing the URL of the page we get from the server will break caching. This is why client side page modifications belong after the hash. But you're right that making it a query on the resource (current shape) isn't the right answer either. Simon's proposed format is that after the hash are two unrelated properties - the resource URL and the command.
(In reply to comment #8) > It's true that the command is more related to the page than the resource. But > the root issue is this is a client side concern. I was thinking about it some time ago. What comes after hash describes the state of the page. For me it is not just the resource (like /file/A), but all things like 'readonly' parameter or commands that describe the initial state of the page etc. So I don't think it is bad to put it all after hash like in the Simon's idea. (In reply to comment #6) > but in the clone scenario, we don't want to specify a resource because we can > infer the workspace from the user. So what would the git clone URI look like? > Just skip the resource part? > > http://localhost:8080/git/git-clone.html#,cloneGitRepository=ssh://git.eclipse.org/gitroot/orion/org.eclipse.orion.client.git > > Or is there some kind of placeholder for the resource part after the hash? I don't see anything wrong with git-clone.html#,cloneGitRepository..., but on the second thought git-clone.html#resource=...,cloneGitRepository=... could be better since we wouldn't have to rely on the order of parameters after hash and it would be more user-readable.
(In reply to comment #9) > but on > the second thought git-clone.html#resource=...,cloneGitRepository=... could be > better since we wouldn't have to rely on the order of parameters after hash and > it would be more user-readable. Yes, that's a decent possibility but the important thing to me is that we use something along the lines of a URI Template to document what we're doing. I still hold the hope of considering things like this vaguely runtime discoverable. e.g. I'm hesitant to call this stuff API and ideally would want clients to understand URI Templates and do the parameter substitution according to those rules instead of blindly creating the URI manually.
The encoding problems are fairly unpleasant even if we keep our URI Templates simple to avoid parameter ordering issues. URI Templates either want to encode all of the URI reserved characters or none of them and this can lead us to problems as we start trying to have additional parameters after the resource url. At the moment our pages (for the most part) are using: my.html{#resource} ([Example 1] my.html#http://myserver/some/path) meaning that because of the "#" operation "resource" CAN use reserved characters like "/", "?", "&", ";" and unfortunately "," inside it without encoding. The real problem for us is comma because it is used as the delimiter if we want to extend the grammar. For example we cannot use: my.html{#resource, params*} ([Example 2] my.html#http://myserver/some/path,a=1,b=orion) because if any of resource, param keys, or param values contain a comma the parsing done to figure parameter values out is not perfectly deterministic and ultimately I'd be concerned vulnerable to security problems. Instead I think our pages should use: my.html#{resource, params*} ([Example 3] my.html#http%3A%2F%2Fmyserver%2Fsome%2Fpath,a=1,b=orion) which of course looks horrible however is in reality more verbose than what's needed. For deterministic parsing we only require "," to be encoded although more encoding is also fine. If we can annotate the template to indicate that only "," needs to be treated as reserved we should be able to legitimately say that the expansion in [Example 2] and [Example 3] are equivalent. I need to fix my expand code to accept an annotation on reserved characters and check that my parse code will treat the expansions for [Example 2] and [Example 3] as equivalent. If not concerned about looks then the fully encoded expansion is always valid as the annotation is a hint and not mandatory for an implementation to understand. -- So... my.html#(resource, params*) is the URI Template we should be using. As I mentioned on the call we're not getting a ton of help from URI Templates in terms of documenting what params are valid and we will still need to document that in some way. I'll send feedback to the URI Template IETF group but they are now late in their own process.
Thanks for you comment Simon. > I need to fix my expand code Is it done? Is there a bug for this I can follow? I'm revisiting the bug at the moment, here is what I've found so far: * We now use git-repository.html page for displaying repos, which doesn't require a resource ie if it's not provided your default workspace is used, but not attached after hash. So the URI like "/git/git-repository.html" is perfectly valid. * I've tried these URIs, but none of them seem to work, the slide doesn't show up. This is expected for the last two, but I was hoping the first will work. The second gives me a syntax error. ** /git/git-repository.html?cloneGitRepository={URL} ** /git/git-repository.html#?cloneGitRepository={URL} ** /git/git-repository.html?cloneGitRepository={URL}#/workspace/{id} ** /git/git-repository.html#/workspace/{id}?cloneGitRepository={URL} * To see the slide, visit /git/git-repository.html#/workspace/{id} first and then add ?cloneGitRepository={URL} This can be considered as a regression comparing to the old git-clone.html page so I guess we'll need to sort these things out first.
The new repo page is updated to support command bindings. Try now.
(In reply to comment #11) > my.html#(resource, params*) is the URI Template we should be using. Simon, in case the resource is omitted (undefined) is my.html#a=1 valid? To use a real world example: should /git/git-repository.html#?cloneGitRepository={URL} work? Right now it prints "Unable to load cloneGitRepository=https://github.com/zaza/stocks-updater.git status:404" as it tries to find a repo with that name.
(In reply to comment #13) > The new repo page is updated to support command bindings. Try now. Thx, I've updated the scripts -- 83e29e01b8b0eb1a05cf630446589a5ebd3b3e9f
Linking to bug 363960 where the work is being done.
Fixed as part of bug 363960
