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(a)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(a)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(a)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(a)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(a)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(a)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(a)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
--
Thanks,
L235
<https://en.wikipedia.org/wiki/User:L235>
https://en.wikipedia.org/wiki/User:L235
_______________________________________________
Maintainers: Cyberpower678, Technical 13, MusikAnimal, Elee, Nakon, L235
xTools mailing list
xTools(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/xtools
_______________________________________________
Maintainers: Cyberpower678, Technical 13, MusikAnimal, Elee, Nakon, L235
xTools mailing list
xTools(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/xtools
_______________________________________________
Maintainers: Cyberpower678, Technical 13, MusikAnimal, Elee, Nakon, L235
xTools mailing list
xTools(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/xtools