Skip to content
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

Additional Validations - URL and Lat-Long validation improvements #46

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Conversation

dazyoung
Copy link
Contributor

A few updates have been made to the validations.

  1. I noticed that some URLs which were working, were still not valid. This was caused by non standard characters appearing in the host name which breaks with the RFC2396 which java.net.URL uses.
  2. Related to Convert German coordinates from 7°48'31.0"-like format to decimal #41 , I have added some validation checks on both decimal and DMS (e.g. 17°38'15.60"E) style coordinates. The DMS style coordinates are validated when the input is not a float value and conforms to a regex which I have defined. The regex is probably not flawless but covers all cases which I threw at it as well as not letting extra stuff through.

Added bounding checks on decimal coordinates.
Added tests to cover acceptable DMS formats.
…i/Punycode)

of the host name to accommodate for urls which are valid (working) but not
standard (do not meet the requirements of RFC 2396 as used by java.net.URI).
@dazyoung
Copy link
Contributor Author

dazyoung commented Oct 7, 2017

@nicolas-raoul debating where would be best to make this update.
As far as I can see, the two viable points are:

  1. at the point of reading (i.e. when constructing the listing in German.java).
  2. after reading, when outputting to the various output formats.

The advantage of Option 1 would be that we don't make totally unnecessary checks (e.g. is the lat-long in DMS or Decimal format). Basically, a consistent way of handling the data right through the process

The advantage of Option 2 would be that data gets to work it's way through the validation process as before. Option 1 has the disadvantage of effectively short-circuiting out invalid entries before the validation process takes place. We would however need to check the format each time on output to determine where conversions were necessary however by this point.

Any thoughts on this would be appreciated, it is not a difficult issue to resolve, but undecided on where the most appropriate place would be to perform this conversion.

@nicolas-raoul
Copy link
Collaborator

nicolas-raoul commented Oct 8, 2017 via email

@nicolas-raoul
Copy link
Collaborator

Hi @darrenyoung89 !
We have changed how validation works (see commit 7d2abc7), so now it should be quite straightforward for you to put validation at the right place :-)
Cheers!

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.

2 participants