appreciation in the MediaWiki community
I am writing to express support for your work on WikiDB and also to say that it is disappointing that the importance of this type of effort does not seem to have been appreciated in the MediaWiki community.
I was wondering whether your work might not have a greater chance of support and indeed inclusion into MediaWiki if it wasn't (at least initially) more focused on a specific and perhaps more urgent problem, which I'll illustrate using the example of artists and their works.
To be quite concrete, here's the problem description.
The "infobox" for artists should provide detailed information based on a template and data in a table. For simplicity, I'll assume that it's just one row in a single table.
The "infobox" for a work of art should similarly be based on a template and data which (for simplicity again) I'll assume comes from two tables - one for artists, and the other for works of art. The data about artists that appears in the works infobox would presumably be a small subset of the available data, e.g. just the artist's name, birth and death dates.
The basic requirement then is to have a way to construct a pretty infobox based on one or two rows of data. The trickiness is how to specify an artist (assuming that combinations such as name, birth and death names will not suffice).
In other contexts, one could (perhaps) use the ULAN system for artists, but that is unsatisfactory if there is even a single artist for whom a ULAN number has not (yet?) been assigned.
A hash of the basic data would be OK if that data was invariant, which is not likely. An accession number is error-prone and raises portability difficulties, but so far as I can tell would probably be the best general approach. Anyway, let's suppose an accession number is used.
For this to work, I believe that a "data-driven data entry form" for creating a record will be needed. Let me explain why.
We can use the template mechanism for defining new tables, but there has to be a way to perform the usual database operations. This effectively requires a form whose content is determined by the table definition.
For example, let's suppose Template:Define Artist defines the fields of the Artist table in some declarative manner. Then Special:Table page would allow all the CRUD operations:
- Special:Table&table=Artist&action=edit (create a new row)
- Special:Table&table=Artist&action=view&id=NNNN (view the specified row)
- Special:Table&table=Artist&action=edit&id=NNNN (edit the specified row)
- Special:Table&table=Artist&action=delete&id=NNNN (delete the specified row)
- Special:Table&table=Artist (view all the defined artists)
- Special:Table&table=Artist&select=surname=Lin (view matching artists)
This scheme I believe resolves all the significant issues except one:
- What happens to existing records if the "Define Artist" template is changed?
Simplicity, I believe, would argue for adopting a rule to the effect that a table-defining template cannot be changed if there is any data that would be invalidated. This would, for example, allow more fields to be added, or the name of a field to be changed if there were no records with a value for that field.
Peter Koppstein (email@example.com)
The Consumerium development project
Hello there HappyDog. I've been the lead developer/researcher/designer/strategist for The Consumerium development project That wiki is now closed for editing (the wiki got badly spammed-out/vandalised making contributing almost impossible. Also internal incoherence reached a level due to many changes in the design paradigm that effectively obstructed making sense. But the work continues now in http://en.consumeria.info/wiki/ (Which is an attempt at an "implementation"-phase).
I invite you most warmly to register there so we could discuss how WikiDB could potentially be a solution to some serious problems regarding redundancy and needlessly high level of manual editing. I also sent you some emails but have received no reply. Otoh it might be better to discuss WikiDB and it's future development lines and application to making Consumeria a reality here, in this wiki, might be a better idea as it might attract more interested individuals to this development wiki if there were active discussions/planning going on around here.
The mission statement of Consumeria is simply to "enhance consumer informedness" and I really hope it is a cause that more people would find worth pursuing. Anyways, WikiDB extension seems very well thought out and promising. Best wishes --Juxo 18:43, 3 October 2007 (BST)
Simply amazing! Keep up the good work. I do dabble in PHP and SQL, so if I can be of any help, i'll try to help out where I can. I'm not an expert programmer, but if I can help. I would love to. I'll check my user page here occasionally if you need some help. Tazzy 01:14, 19 January 2008 (GMT)
- Thanks Tazzy! There is some active development going on at the moment which will open the door for some cool new features soon... Keep checking back for more info! --HappyDog 01:09, 29 January 2008 (GMT)
Questions concerning transclusion/inclusion within a namespace
Hi there! First I want to thank you for the wonderful NonincludableNamespaces-Extension. I was wondering if you have any ideas how to allow include actions within a namespace, but disallow them inbetween namespaces. Is there something like an inclusion-from / inclusion-to concept?
- Thanks. As far as I know there is no way of doing that, but there are hundreds of extensions out there, so you may be able to find something. The NonincludableNamespaces extension is purely to provide this now-standard MW functionality to earlier versions of the software, so it is not something that I would consider adding extra this feature to. --HappyDog 14:24, 10 March 2008 (GMT)
- Thank you for the response. So... good reason for me to understand the nuts and bolts of the mediawiki code. Wish you a nice weekend. Thank you for the response. --22.214.171.124 16:25, 30 March 2008 (BST)
I love you HappyDog
I love you HappyDog, what a great Extension?? Hope to see a new verison soon. Jimmy Jimmyyami@gmail.com
- Thanks!! :-) --HappyDog 10:51, 21 July 2008 (BST)
HappyDog, What Do You Think Of...
HappyDog, first off for taking an interest in this effort. It is hugely important to me that someone has finally decided to work on this.
My question pertains to the possibility of how I might use this on my Wiki.
Our site specializes on rare NASCAR racing results. We would very much like to mimic the style used by a major series reference sheet without compromising the flexibility and editabilty of our tables. Ex. 2002 Aaron's 312 Race. If you clicked on that race you would view race results (simple, right?). However, when you click on a driver's name (say winner Jason Keller), you would get a very detailed (and obviously very finely tuned query code) individual database. Obviously, typing in data for every driver manually is a pain.
Do you think your extension could encompass that idea. I know I would have to do some work to get the query as effective as that, but it'll be worth it. If you think it'll work, I'll gladly get the extension installed and give you feedback. -DaNASCAT (on Wikia)
- I think it should do what you want, at least in theory. The query syntax is a bit basic at the moment, but what you want should be possible - if not, then that's something that needs fixing! I suggest installing the latest version and trying it out - please let me know how you get on! --HappyDog 14:04, 9 September 2008 (BST)
PersonalisedHomepage extension compatibility with Mediawiki 1.18
Do you have any plans to update your PersonalisedHomepage extension for Mediawiki 1.18? Currently it fails with this error displayed in the browser:
Fatal error: Call to a member function addMessages() on a non-object in C:\Inetpub\wwwroot\mediawiki-test\extensions\PersonalisedHomepage\PersonalisedHomepage.php on line 45
Sure enough the $wgMessageCache object that's referenced on line 45 is removed in MW 1.18.