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
Enhancment: @metadata in ranges.json #115
Comments
Can you sketch out what this metadata might look like with an example or two? |
E.g. Creeper.json |
I've used something like |
So my solution was simply to add the above to the top of my range files and then add: |
Delinting using http://www.coffeelint.org/ Adding throttle parameter to config (but set to false) to highlight that it exists Adding tripple mustaches to deal with issue edsu#116 Adding namespace logic to anon and config to support issue edsu#118 This allows filtering out edits in talk namespaces etc, if namespace is left out of config all namespaces are accepted Added logic to disregard @metadata entries in ranges to support issue edsu#115 this allows source, dates etc. to be added to the ranges
Why not let the metadata live in a revision control system like git? |
People curious about which ranges are being used will often just look at the json file. If metadata is available there (I'm mainly thinking source etc.) then it is easy to spot where it is from and even easier to reuse the ranges. The reason for adding the "last update"-date in the file is similarly that it makes it easier for others to highlight if the file is out of date/there has been an update in the original source. I removed this from the patch in order not to block the other fixes. |
I'm sorry I just haven't needed this functionality. |
For a completely externalised ranges.json file it might be nice to add an "@metadata" object containing information such as source of ranges, last date they were verified etc.
I'm currently unsure how adding a field like this would be handled by the app since I can't figure out how it deals with incorrectly formatted range objects. If it does throw a wrench in the works would it be possible to make it skip name=@metadata (or some similar convention)?
The text was updated successfully, but these errors were encountered: