Advanced

Tag config

Tag config
June 05, 2016 01:07AM
I'm doing a checker that uses country/region/county names to spell a word (since titles are no longer allowed). For flexibility, I was thinking to offer users these variants of places the user has finds:
1. Use only all counties in a country and region
2. Use only all regions in a country
3. Use only all countries
4. Use all countries, regions and counties (should be the easiest qualifying set for those who travel infrequently)

I was thinking to have the tag config for these look like:

1. { "country": "United States", "region"="California", "county"=[ ] }
2. { "country": "United States", "region"=[ ] }
3. { "country": [ ] }
4. { } or perhaps { "country": [ ], "region": [ ], "county": [ ] }

Then the [ ] for say #1 could become {"country": "United States", "region": ["California", "Arizona"], "county": [ ] } to represent "use all counties in California and Arizona. In general, any of the [ ] values could be constrained in this way if it suited the user. I assume an empty array shows up as an empty table in the config data. Is that right?

I'm not sure what omitting country but using region should do? Would this be any region with that name anywhere in the world? I've seen a tag using just a region name in Germany.

Does this seem a reasonable way to provide a suitably flexible configuration for challenges of this type? I'm new to this so wanted to check in case there is some other syntactic convention for this sort of thing in use.

Thanks.
Re: Tag config
June 05, 2016 03:09AM
If you look at the GetFindes documentation http://project-gc.com/doxygen/lua-sandbox/classPGC__LUA__Sandbox.html you will notice that there are build in filter options in the api call
Use them because they will be translated to SQL where statements that is used to fetch the user finds. It is faster/easier to use them then to implement your own in LUA
The code to add the filter options from the config is as simple as below if the options are in the top level of the tag. If you require a filter table in the config it is even easier when conf.filter can be used directly in the API call
I have not testet to send an empty array to the filter so i would not require "county": [ ] If you allow it to be missing the checker will work lite most others checker

Most checker uses the filter options named as in the GetFinds directly in the config tag

One thing consider is to add code that allows known config option it the config and result in an error if other tags is added. That will reduce the risk of a misspelled .
I have an extended GetFinds in this checker template that can be used. It haves more filter options.
http://project-gc.com/Tools/Challenges?edit&scriptId=936
I will extend it with attributes, FP, %FP, %wilson, elevations and perhaps other options. A polygon filter might be used

The core i have often used is the one below. You can if you want set local filter=conf and it will still work but that dont look as nice in my eyes

local filter={}
filter['country'] = conf.country
filter['region'] = conf.region
filter['county'] = conf.county
filter['minVisitDate'] = conf.minVisitDate
filter['maxVisitDate'] = conf.maxVisitDate
filter['minHiddenDate'] = conf.minHiddenDate
filter['maxHiddenDate'] = conf.maxHiddenDate
filter['types'] = conf.types
filter['sizes'] = conf.sizes
filter['difficulties'] = conf.difficulties
filter['terrains'] = conf.terrains
Sorry, only registered users may post in this forum.

Click here to login