Well, as with all things, there are several approaches to solving the prolem
In a single function, branch on the tag name to use
the appropriate
SqlServer object, and pass it to a single, general function
If your function is a method on an object (instead of a 'global' function),
then when you're creating the hooks, you can instantiate a new instance of
the extension class for each hook, and in the object itself, keep a
reference to which DB to hit. (I think this is the closest solution to what
you want to do, but read on for more suggestions)
OR, you might be able to have your function take an additional parameter,
which you set statically in the $wgParser->setHook() call when you initially
specify it (I'm less sure about this option)
OR, you can use a Parser Function instead of an extension tag to do your
bidding
so instead of <sql server="servername">whatever</sql>, you'd
have
{{#sql:servername|whatever}}
Then, since parser functions happen higher up in the Parser->parse() stack,
you can make templates such as [[Template:servername]] which contains
{{#sql:{{{1}}}|{{{2}}}}}, and would be called as {{servername|whatever}}
Of course, the output to a parser function has to be wikitext instead of
HTML (unless you do some hackery to get around this), but you can use it in
templates ad nausium. So it has pros and cons.
In summary, there are a number of different ways to achieve the same desired
result if the problem statement is presented in a broader fashion. ;) This
is often the case in MediaWiki extension development.
-- Jim
On 6/6/07, Daniel Barrett <danb(a)vistaprint.com> wrote:
Jim Wilson writes:
There are a couple of different ways to get at the
information that you
require
without necessarily pulling it from the tag
execution at "run time"
as it were.
Since you're the one setting the tag name, you should know what it's
called, right?
True, but I am trying to write some highly reusable/maintainable code
where the tag name is just input data, since the MediaWiki programming
model to "statically map tags to parser functions" doesn't seem optimal
for our situation. Here's the scoop.
At my company, we have many database servers. For each server, we have a
separate wiki tag, <server name here>, that allows adhoc queries to that
database server. All these wiki tags have the same implementation, but
direct the operation to the named database server. We could have done
this instead with a single tag, e.g., <sql
server="server1">...</sql>,
but for convenience of our wiki users (as well as legacy reasons), we
have one tag per server.
Right now, whenever we add wiki support for a new database server, we
have to modify several pieces of code by hand to add the wiki tag:
1. Create the parser function (very short, just a wrapper that calls a
more general function using the specific server's connection string)
2. Create a new setHook call
3. Append the tag name to the $wgExtensionCredits 'description' entry
4. Possibly create a bunch more parser functions & setHook calls in the
future, for new purposes
This is for EACH server we add. It is a maintenance pain as the number
of servers grows, and requests for new kinds of database functionality
are growing too. So I want to refactor things to abstract away the
servers, make things completely data driven, and stop adding code.
In the new model, I simply maintain a collection of "SqlServer" objects
that represent the servers. To add support for a new server, I'd just
add it to the SqlServer collection and be done. No other code-writing
involved. All the above 4 steps go away.
But in order to do this, I need to detect the tag name which invoked the
extension, so I can do the following:
- Get the tag name
- Generate all the necessary setHook call(s)
- In a single function, branch on the tag name to use the appropriate
SqlServer object, and pass it to a single, general function
I hope this explanation makes sense.
DanB
---------------------
Confidentiality note
The information in this email and any attachment may contain confidential
and proprietary information of VistaPrint and/or its affiliates and may be
privileged or otherwise protected from disclosure. If you are not the
intended recipient, you are hereby notified that any review, reliance or
distribution by others or forwarding without express permission is strictly
prohibited and may cause liability. In case you have received this message
due to an error in transmission, please notify the sender immediately and
delete this email and any attachment from your system.
---------------------
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/mediawiki-l