Pretty much. The Communication class will do the big labor of efficiently collecting and organizing the raw data. The tool simply makes use of the data, and processes it as needed, and then throw that data into the Smarty template. No DB calls, initializations, API queries, nothing. It’s all graciously handled by the communication class. I will start working on the Communication class tonight, and create some stuff to put in a config file.
But I am reminded on one thing. We need to respect optin consensus globally. At current global consensus favors optin, while enwiki has no opt.
Cyberpower678
English Wikipedia Account Creation Team
Mailing List Moderator
From: xtools-bounces@lists.wikimedia.org [mailto:xtools-bounces@lists.wikimedia.org] On Behalf Of MusikAnimal Sent: Wednesday, July 22, 2015 11:46 AM To: Discussion list for xTools Subject: Re: [xTools] Wikihistory is here
Well I must say Communication::getArticleInfoData() is very nice on the eyes :) I think you've won me over just on that!
We can adapt the queries from the old xtools, no? That way our devs already have that ready for them. From there it's just calling the fetch data method and rendering the template.
So for a given tool, on a high level the developer would do something like (1) convert all the markup to templates (2) once the form is submitted (or relevant URL parameters are provided) do the query via Communications class (3) render data in templates (4) Go drink a beer. Am I missing anything?
On 22 July 2015 at 11:10, Maximilian Doerr maximilian.doerr@gmail.com wrote:
Hmm. I’m still more keen on putting all queries in one file and simply having the tool run a function called, Communication::getEditCountData();, or Communication::getArticleInfoData(); The Communication class will basically normalize/universalize the formatting of the data to fit the tools’ needs. Any change to the DB or API can be met with an easy fix to the class, be it how the data is returned, or what string is needed to get the data, without having to modify any other code on the tool. As for queries, logically the answer is yes. We only query what we need, or it will end up taking 4 days to run the query. :p We should avoid frameworks. If anything we should create our own basic framework, like the Communication class I suggested, which does all the data retrieval labor. It’s got to be something we can all understand, and modify as necessary.
Cyberpower678
English Wikipedia Account Creation Team
Mailing List Moderator
From: xtools-bounces@lists.wikimedia.org [mailto:xtools-bounces@lists.wikimedia.org] On Behalf Of MusikAnimal Sent: Wednesday, July 22, 2015 10:59 AM
To: Discussion list for xTools Subject: Re: [xTools] Wikihistory is here
Hmm, I could go either way with this. Personally I might be more fond of separating out responsibilities to each tool entirely. The idea being if we updated one tool we wouldn't have to worry about it breaking the other tools. If database or API changes occur we might just as likely have to update the code that handles the data. An example would be when a column is renamed (although very unlikely to happen!), so you'd have to change the code that reads the API/db response.
Refactoring is of course a good thing, but maybe restrict it to the actual API/db query functionality (like a wrapper or something), and not the queries themselves. So if you had a dbquery/API wrapper, from each tool you could pass it the specific SQL/parameters you want, and the wrapper would take care of anything common to all queries, such as handling of continuation data. This is what I would envision a "communications class" to entail. For each tool, you could define the SQL queries that it uses at the top of the file for easy reference. My thoughts are they wouldn't change much, except for optimizations.
For performance reasons and for the user experience, we only query what we need for a given tool, right? For instance, if I use the Top Edits by user tool, it's not going to use the same SQL queries as the edit counter? If this is true, which I think it should be, I don't see many queries that would be shared amongst tools anyway. They all sort of do their own unique thing.
That's my two cents, but as the developers you guys should decide what's best.
Just so we're clear, I think we've ruled out usage of any frameworks, correct? Just the templating engines? So long as there's no backend code in the markup I think we'll be making a huge improvement over the current codebase.
On 22 July 2015 at 09:15, Maximilian Doerr maximilian.doerr@gmail.com wrote:
I had tweak a bunch of code to even get it to work, not to mention replace a whole bunch of deprecated functions. People seem to love those these days. I’m in the process of taking over a script from Chris G Bot, and again lots of deprecated functions. :/ I can try to see if I can unlock the namespace lock, but I need to find out where that is happening.
As for xTools, with a temporary solution now in place for articleinfo, I believe we can start working on a rewrite for xtools. We already have smarty templates, so interface shouldn’t be a major concern. I propose we break the workload up tools, and assign an individual tool to a user, while one other user writes the code for communicating to the proper medium to get results. Another idea is to write a Communication class and put it in a file call communincation.php. It will essentially do all the querying needed to get the results in one go for any tool. This means that all the query strings for the API and the DB, will be saved in this class. I think this is a preferred solution as this will allow us to easily make necessary changes to queries in response to any API or DB changes we encounter, without having to sift through the code. Another thing I propose is the addition of a configuration file such as config.local.inc.php and config.inc.php. This would be the location where hardcoded OAuth settings and file paths would be stored, or anything hardcoded that may need to be modified to move the tool. This will allow us to make the tool mobile and allow us to be able to set up a local installation about as fast as it takes to say “pi”. If anyone has some objections, I can start fashioning up some efficient communication codes and create the class, as well as some things to put in the config file.
Cyberpower678
English Wikipedia Account Creation Team
Mailing List Moderator
From: xtools-bounces@lists.wikimedia.org [mailto:xtools-bounces@lists.wikimedia.org] On Behalf Of MusikAnimal Sent: Tuesday, July 21, 2015 11:08 PM To: Discussion list for xTools Subject: Re: [xTools] Wikihistory is here
Awesome!!!! Great work Max! :)
I've updated [[MediaWiki:Histlegend]] to link to this for mainspace pages, and to the old xtools for other namespaces, as I figure that's better than the "article not found" message WikiHistory throws.
So I assume it's probably too much work to make this work for any namespace? Seemingly it would not be, as the API is uniform for any namespace... but hell if I'd know :)
Kudos!
On 21 July 2015 at 21:12, L235 Wikipedia l235@l235.net wrote:
Congratulations - have you made an on-wiki announcement?
Regards from Chansha, Hunan Province, China
L235
On Wednesday, July 22, 2015, Maximilian Doerr maximilian.doerr@gmail.com wrote:
Ladies and gentlemen. Wikihistory is now available for use on en.wikipedia.org. You can find it at http://tools.wmflabs.org/xtools/wikihistory/ J
Cyberpower678
English Wikipedia Account Creation Team
Mailing List Moderator