hoppfrosch wrote:Started testing yesterday - looks already usable.
Thanks for trying - fixed the empty SKAN md5 entry - got caught up in trying to make sense of the posts on the other forum as they don't look right due to forum upgrade and forgot to delete it before comitting it - I won't make any further additions to the database as we have a nice test sample now to finish the main script and decide on a final format.
hoppfrosch wrote:The biggest problem I see is to keep the database up to date
Indeed, and in that light your remarks below are interesting but also add additional work which we might do in future but perhaps should not do right now. Lets build a
Version 1 database first and see how far it goes - if there is no interest apart from 2-3 people there is no point in putting in a lot of effort.
hoppfrosch wrote:I have a few suggestions/questions for the beginning:
[*]Don't use the ini-sections as content of the name column in GUI.
Alright, as noted in the documentation in case of a duplicate entry simply add a (serial) number to the name, for example JSON2, JSON3. So what do you suggest to have as section heading instead? A sequential number like Tuncay had?
hoppfrosch wrote:[*]It should be avoided to get too many tags; they should be standardized.
I was in doubt about the tags, I thought and still am thinking about ditching them. Standardising wouldn't be to difficult and simply checking for allowed tags only is not a problem either. The reason I kept it in for the time being is that I was contemplating to have a treeview next to the listview with the tags so you could click them and have it act as a filter or perhaps a listbox next to the searchbox. Removing them saves people the trouble of comming up with good tags as well.
hoppfrosch wrote:
[*]Before adding entries to the database, there should be some quality assurance:
- Are all required fields filled out?
- Is the provided data valid? For example: are the provided links reachable? Or: Are all used tags valid? (see suggestion above)
Extracting the urls from the database and then using a link checker is not very complicated so could be done at regular intervals.
hoppfrosch wrote:
[*]Enhanced keys/New Keys
OK that might be a nice addition, if an url is present a link in the Gui should be made available for the user to click and visit the profile/website of said user.
hoppfrosch wrote:
[*]New key: Validated(?), having a date-timestamp as value. This can be used to identify "old" entries within the database and should be updated by database maintainer from time to time (script-based? Checking validity of links ...)
That might be something worth doing if we'd start to use your cards idea below. Those cards that don't validate are excluded from the main database and marked for Revision/Inspection.
hoppfrosch wrote:
[*]Keys indicating the AHK-compatibility (Version: 1.0.48-1.1.xx-2.x-all, 32bit-64bit-all, UNICODE ...)[/list]
Personally I'm only interested in AHK 1.1+ material, that is why a lot of material from Tuncays collections should no longer be included in pAHKlight (for example the excellent AHK Basic COM library by Sean - there is simply no use for it any longer) - As v2 is still in beta there is a) very little AHK2 specific material and b) once v2 is actually more or less finalised it would simply be a matter of starting a new database with specific v2 material and allowing the user to load the AHK 1.1 database or the v2 database.
If something is specifically 64 bit only you could just as well mention in at the start of the description or in the full name: "MD5 - (64bit)" for example. And a user can of course read the forum or perhaps ask the author to make a ansi+unicode version of something.
hoppfrosch wrote:Another idea for "database": Using a storage place ... its own "business card"
I think that is actually a nice idea when the database becomes larger. Creating individual records - which should be files I think (just for speed reasons, not on the forum as only one person could edit a post and the Wiki is a bit slow if you start downloading hundreds of pages) - would indeed make it easier to maintain and check. Of course it will be very easy to split the currenty INI database into individual files and then build an automatic validator and database builder script etc.
Thank you for your input so far.
I have the following questions:
1A: Should we keep the tags or ditch them?
1B: If kept they should be standardized as you say, but should they be incorporated in the Gui as search filter either as treeview of listbox?
2: Should we allow Author link in author name as suggested above? + A link in the GUI if we do.
3: What to use as section name instead of the current [name]? Sequential numbers?
[record1]
[record2]
[record3]
etc?
4: Should I add to the following to the main script?
4A: A "Try Google" button which takes the search query and runs Google Custom search
General:
My main idea is still to keep things as simple as possible to get something worthwhile - once it has some momentum expanding the system behind it (indiv. cards, validation, etc) could be done. We can make small helper scripts already (checking format, simple Data entry Gui etc)