What I did on my Saturday...
Sep. 12th, 2010 10:13 amBesides translating four short-ish documents, I spent quite a bit of time - probably too much - solving a few issues having to do with PHP.
The primary of these had to do with figuring out how to have the program figure out (a) what glossary file to refer to, as I want to have separate glossaries for different subjects and languages, and (b) how to invoke itself, as that's how the code operates.
With one glossary file, neither of these is a problem: you just specify file name and the name of the program in the code (so-called "hardcoding"). When there are several alternatives, on the other hand, one thing you don't want to do is create multiple copies of the code, each one slightly different, the difference being the specification of the data file and the code itself. Trying to maintain that kind of setup would be a nightmare.
As an alternative, you could create a configuration file that specifies the appropriate information to be used with one copy of the code, but then the code would still need to contain (or generate) some piece of unique data to figure out what specified information to use.
Instead, I learned how to use the WordPress get_permalink() function, which returns a string with the URL of the current WordPress page. By stripping off everything from the URL but the unique page identifier, it turns out I don't need no stinking configuration file, because I can use the identifier as part of the data file name (e.g., fopen("glossary_7.txt", "r")), and in the code for the form on the page (e.g., action="?page_id=7").
I had a beer to celebrate.
Cheers...
The primary of these had to do with figuring out how to have the program figure out (a) what glossary file to refer to, as I want to have separate glossaries for different subjects and languages, and (b) how to invoke itself, as that's how the code operates.
With one glossary file, neither of these is a problem: you just specify file name and the name of the program in the code (so-called "hardcoding"). When there are several alternatives, on the other hand, one thing you don't want to do is create multiple copies of the code, each one slightly different, the difference being the specification of the data file and the code itself. Trying to maintain that kind of setup would be a nightmare.
As an alternative, you could create a configuration file that specifies the appropriate information to be used with one copy of the code, but then the code would still need to contain (or generate) some piece of unique data to figure out what specified information to use.
Instead, I learned how to use the WordPress get_permalink() function, which returns a string with the URL of the current WordPress page. By stripping off everything from the URL but the unique page identifier, it turns out I don't need no stinking configuration file, because I can use the identifier as part of the data file name (e.g., fopen("glossary_7.txt", "r")), and in the code for the form on the page (e.g., action="?page_id=7").
I had a beer to celebrate.
Cheers...