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(a)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
_______________________________________________
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