Good day,
Here are few comments/suggestions about the scripts.
1) The overall product is really great, good job Chad!
2) The "ExtractReferrerDomain()" function is "choking" badly when the hostname doesn't have a period in it. For example, I did some tests localy, and the script ran extremely slow when processing the host entry "localhost". In fact, it is MUCH slower when there is no period in the hostame, would it be "localhost" or anything else without a period. In fact, the same thing is happening for the entries matching my other computer, which I used at times for tests.
Perhaps an addition in the DomainExtension array with the proper RegExp would alleviate this situation, I don't really know. For the moment being, I return the hostname as being the domain name when this is occuring, skipping the DomainExtension validation process.
3) The report page, "default.asp" as per the distribution package, may not render correctly on some browsers it they're picky about the html tags. I detected unbalanced tags on mine (v 1.200 b3) which needed to be fixed prior to bring the page in my web authoring program and add few customization.
4) To ease the updates of the lookup arrays, I moved the data in a separate configuration database. The arrays for the Browsers, Domain Extensions, Language Names, Operating Systems, Referrers and Robots, each have a separate table in the database. The arrays are populated from the DB only when necessary via GetRows, which works like a charm. The only drawback, is to adapt some part of the code referencing these arrays, as they aren't dimensioned in a same way, but overall, I think it was worthing the extra time to do it as it will simplify the updates.
5) There are 2 reports showing the links with the "little plus sign". On the by page report, I modified it so that the links are no longer clickable. The main reason for this, is since the URL is truncated (without the parms), it jeopardises the link validity since the necessary parms aren't there (applicable for dynamic pages). The "by URL" report does the job nicely for that, as the parms are included.
6) Since not everyone has Access 2000, like me for instance, I'm running an Access 97 version of the DB. As per the the script, the compaction is working for A2K, but if it is ran on an A97 DB, it will be converted to A2K, although I can't confirm the integrity. To keep it as an A97 database, the JET specification need to be added to the destination database when invoking the "JRO.JetEngine"
Well, I guess there is some material here to get started on a conversation, right ? Ain't that the purpose of a forum ? ;)
Best regards...
Not really a request, but suggestions.
Good idea,
Another feature that would do, is to implement multilanguage support for helpfiles etc.
Now you have to dig into the code to change the language.
http://www.ocp.be
Not really a request, but suggestions.
Good day,
Putting the multi-language support in place would be a project on it's own.
Under most circumstances, it's "easier" to simply create another file and apply the translation manually, specially when the product is fairly advanced in the development, such as the actual scripts.
When creating a new product, pre-defined text placeholder markers can be used instead of fixed text, then when the page is rendered, it will replace the placeholders with the appropriate words based on the
selected language.
When you add conditions, such as use of singular or plurial, and other syntax rules, this can become a real challenge.
This is how I would personaly do it if I would have to do something like that.
For example, the actual formum program, Snitz 2000, is available in different languages. I don't know how they proceed, but might worth to take a look and see if this is an approach that would be convenient for the MetaTraffic scripts.
Bye for now...