Resending this because it doesn't appear to have reached the archive. (I've got to figure out how to make these use the right address) ~Daniel Friesen(Dantman) of The Gaiapedia, Wikia Graphical Entertainment Project, and Wiki-Tools.com
There is another convention you could use to avoid conflicting with MW functions. Some extension authors have considered w for wiki and e for extension. Also using f for function and g for global. So MediaWiki functions usually have wf and MediaWiki globals have wg. Sometimes when an author needs to make a global instead of using a $wg variable that will clash or a wf function that will clash. They use a $eg (Extension Global) and a ef function.
On another note. Has anyone ever thought of a MediaWiki message commons system? Like how we have an Image Commons system which an image takes the line: -Nonexistant -Commons -Local Meaning that if it's found locally it uses it, if not it falls back to common, if not it's nonexistant.
But what about a similar Message Commons, the current system goes: -Language Files -Messages Added to the MessageCache -Local Database But why not throw in a commons, something like: -Language Files -Messages Added to the MessageCache -Commons Database -Local Database
~Daniel Friesen(Dantman) of The Gaiapedia, Wikia Graphical Entertainment Project, and Wiki-Tools.com
Jim Hu wrote:
Rob,
I wasn't sure if it's better to keep the extra tables in the wiki database or add them as tables to the MW table set. The latter would certainly work, and if that's preferred, it actually makes a bunch of the coding easier, and would undoubtedly make it easier to be compatible with installations that aren't using MySQL. As it is, I'm basically taking advantage of PHP's promiscuous mysql connections to talk to the external db using MW database object methods. I was thinking that I should keep my mitts off the base schema to make sure that I don't inadvertently conflict with some future MW schema change. But if you think I should add tables to the MW ones...
Although I share your dislike of globals, $wgTableEditDatabase will be the setting. For now I think I'll keep it outside unless a groundswell of the other MW devs and folks on the list second your thoughts. I think one could go either inside or outside during installation; if inside, then $wgTableEditDatabase could just be set to $wgDBname.
Jim
On Jul 28, 2007, at 4:49 PM, Rob Church wrote:
On 28/07/07, Jim Hu jimhu@tamu.edu wrote:
I have a couple of questions before I do the next release of the TableEdit extension/special page
- In the TableEdit extension, the table data is stored in an
external mysql database. I had been hard-coding the name of this database into the extension to avoid creating a global variable that the user would put in LocalSettings. But it seems like that was a bad idea, especially if one wants two instances on the same mysql server... which I discovered I do want.
Is it essential to use an external database? Could you not use a number of tables in the same database as the wiki's using?
This strikes me as making life easier in terms of setup, and writing portable code, and also maintenance and backup operations.
Some trickery would be needed if you have to share data between wikis, but you could most likely achieve the desired effect by extending the shared table mechanism (which should be cleaned up, in any case) or using query groups to direct queries to the right database server and configuration, for more complex setups.
If you feel it *is* appropriate to use an external database, then I would certainly recommend making it configurable using a global (I despise globals, but we use them for configuration, so conventions are good). The "wg" prefix is a convention which was introduced to help indicate that a variable should be in the global scope; it helps us to spot missing "global $wgFoo" statements which cause notices, warnings and in some (well, a lot of) cases, downright stupid assumptions on the part of PHP.
When naming such configuration globals, be sensible; pick a name which isn't going to conflict with the core (for the foreseeable future). It's often a good idea to prefix the variable name with the extension name, e.g. $wgTableEditDatabase, etc.
Rob Church
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l