Skip to content

Fix URI generic syntax delimit path components by slash ("/") #105

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 28, 2015

Conversation

hakre
Copy link
Contributor

@hakre hakre commented Jun 9, 2014

Parts of justinrainbow/json-schema are using the backslash ("\") in
error on occasion.

@hakre
Copy link
Contributor Author

hakre commented Jun 9, 2014

This first commit at least fixes the issue for me on a windows test-system.

The issue also highlighted wrong usage of DIRECTORY_SEPARATOR in other places. It also made visible a certain amount of duplicate code between UriRetriever and UriResolver.

@hakre
Copy link
Contributor Author

hakre commented Jun 9, 2014

For reference: URI uses the slash ("/"). See 1.2.3. Hierarchical Identifiers (Uniform Resource Identifier (URI): Generic Syntax; RFC 3986).

If you follow any of these standards, there are existing components that do resolvement of URI parts, for example, you should be able to use Net_URL2 which is pretty robust.

@hakre
Copy link
Contributor Author

hakre commented Jun 9, 2014

Two little refactoring commits on the house to align and remove some duplicate code.

@hakre
Copy link
Contributor Author

hakre commented Jul 24, 2014

@justinrainbow same here.

@bighappyface
Copy link
Collaborator

@hakre would you please rebase the latest?

@hakre hakre force-pushed the patch-2 branch 3 times, most recently from c709553 to 43f7a94 Compare March 26, 2015 20:29
@hakre
Copy link
Contributor Author

hakre commented Mar 26, 2015

@bighappyface: Rebased + refreshed and a little squashed.

@bighappyface
Copy link
Collaborator

My bad, it was all removed in 43f7a94

@bighappyface
Copy link
Collaborator

I think this is a solid refactor and dedup. Thank you.

+1

I will merge this with another +1 from the community.

@hakre
Copy link
Contributor Author

hakre commented Mar 26, 2015

@bighappyface: The curlies have been squared now. Merge like you see fit, but don't let it rot :)

@bighappyface
Copy link
Collaborator

@hakre I am sure one of the other consumers with PRs will help review. Quid pro quo 😄

@hakre
Copy link
Contributor Author

hakre commented Mar 26, 2015

@bighappyface: Was just pushing a bit because this PR was laying around for quite some time. Just let me know if it needs refresh again or there's anything.

@bighappyface
Copy link
Collaborator

@keradus you have been helpful reviewing #134; would you mind looking over this as well?

@keradus
Copy link
Contributor

keradus commented Mar 27, 2015

@bighappyface sorry, don't know this repo

@bighappyface
Copy link
Collaborator

@loucho @onlinesid would you mind reviewing this PR for @hakre?

@loucho
Copy link
Contributor

loucho commented Mar 27, 2015

+1 👍 seems to be working and i like the corrections to the phpdocs

@bighappyface
Copy link
Collaborator

@loucho thanks for the help!

@hakre I am ready to merge this but I didn't expect such a fast turnaround for the review. I just pushed out 1.4.1 based on #132 today, and should have included this PR in it.

The only other PR I see that is close is the work being done on #134. Would you both help us determine a path forward on that work? If it looks like we will spend much more time there, I will merge this today and bump to 1.4.2. If we can make progress on that end soon, it would be nice to wait and roll multiple updates into a single new version.

Thoughts?

@hakre
Copy link
Contributor Author

hakre commented Mar 27, 2015

@bighappyface: I'd say #134 can greatly benefit from rebasing.

I've done the rebasing for the PR here as well. Should I squash the changes here together into one commit?

@bighappyface
Copy link
Collaborator

I think a single commit is best, but the rebase you have performed is great. I agree with the rebase for #134 and we can take care of that up once we determine how to tackle better validation error messaging.

@keradus
Copy link
Contributor

keradus commented Mar 27, 2015

IMO all PRs should contain one commit per author.

@@ -72,7 +72,7 @@ public function generate(array $components)
* Resolves a URI
*
* @param string $uri Absolute or relative
* @param type $baseUri Optional base URI
* @param string $baseUri Optional base URI
* @return string Absolute URI
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return annotation should be separated due to PHPDoc

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

more context.

* Guarantee the correct media type was encountered
*
* @throws InvalidSchemaMediaTypeException
* @param UriRetrieverInterface $uriRetriever
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then parameter should be typehinted

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done.

@keradus
Copy link
Contributor

keradus commented Mar 27, 2015

This is a fix, but no new tests were added...

@bighappyface
Copy link
Collaborator

@keradus I think we are good here. The test suite provides regression testing for this refactor:

https://github.com/justinrainbow/json-schema/blob/master/tests/JsonSchema/Tests/Uri/UriResolverTest.php

@keradus
Copy link
Contributor

keradus commented Mar 27, 2015

and now the docs is lying ;)

@bighappyface
Copy link
Collaborator

@keradus do you mean the various comments you made on the annotations? I am sure @hakre will adjust.

@keradus
Copy link
Contributor

keradus commented Mar 27, 2015

Just to show we are not good yet here ;P

Parts of justinrainbow/json-schema are using the backslash ("`\`") in
error on occasion.

This fixes the issue in **UriResolver** as well as in **UriRetriever**.

With this commit, the *overall* usage of that DIRECTORY_SEPARATOR
constant has been redacted out of this project.

Additionally in a refactoring duplicate code has been removed from the
classes afterwards and some minor CS fixes have been applied.
@hakre
Copy link
Contributor Author

hakre commented Mar 28, 2015

Just squashed into one commit. Also went through the comments by @keradus - thank you for taking the time to review. Technically it's correct about the test but I also think it's OK to have this lifted as this PR is mainly maintenance and low-level improvement today. The original fix isn't part of it any longer 100%. It just has over-lived itself in part.

@bighappyface
Copy link
Collaborator

@hakre thank you for the squash and response to feedback. Let's merge this in and include it in the next version bump.

bighappyface added a commit that referenced this pull request Mar 28, 2015
Fix URI generic syntax delimit path components by slash ("`/`")
@bighappyface bighappyface merged commit 34e2982 into jsonrainbow:master Mar 28, 2015
@hakre hakre deleted the patch-2 branch March 30, 2015 18:46
@hakre
Copy link
Contributor Author

hakre commented Mar 30, 2015

@bighappyface ACK, cleared here locally. If you have some other older rotten PR you'd like to see refreshed, let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants