On Dec 18, 2013, at 3:30 PM, Rob Lanphier <[email protected]> wrote:
> Hi everyone, > > Everything I said below still stands, except now there are only two days, > so please make the most of them. > I have been working on some draft proposals here: https://www.mediawiki.org/wiki/User:Owyn I think that a few of them are ready for feedback so I have moved them onto the list. Some of these ideas are things that Wikia has already implemented to some degree or another, and some of them are just things that we’d like to see some discussion about. https://www.mediawiki.org/wiki/Requests_for_comment/MVC_Framework - We have our own mvc framework that we’ve used to build pretty much everything in the last 2 years. The developers don’t complain about it, so it must be relatively decent. :) The original design came from Inez (who is working on VisualEditor now) and myself, and it’s been hacked up a bit from where we originally started but we think the core of it is an improvement over QuickTemplates and XML. https://www.mediawiki.org/wiki/Requests_for_comment/UserMailer_Refactor - We usually stick to the normal extension/hook mechanisms for our own stuff, but in the case of the UserMailer it was impossible, so we had to modify it heavily. A lot of the things that we added are basic features like priority and categories (used by our mail sending backend) and the ability to send HTML mail. The User Mailer is an example of a core class which is not designed to be extended, and it probably should be refactored. https://www.mediawiki.org/wiki/Requests_for_comment/OutputPage_Refactor - The output page class is another monolithic class which is a mixture of output pipelining/sequencing functions and helper functions. It creates a lot of data which is used by the skin, but also emits raw HTML and headers in a way that makes it hard to override functionality. A lot of this could probably be split up to separate the data from the rendering of the HTML page. https://www.mediawiki.org/wiki/Requests_for_comment/SQL_Framework - This one is more for fun but it does address something we feel is a pretty big deficiency in the core API's. We wrote a fluent style SQL library and we’ve started using it to build SQL queries in our more complicated data/reporting extensions. We like it a lot better than the core mediawiki database interface which uses positional arrays of key/value pairs. The current database api makes it almost impossible to visualize what the actual SQL is going to be, so you have to just run the code and capture the debug output. With this library, you can build up a query as an object. It has some nice side effects like the ability to cache results without extra boilerplate, and efficiently transform the query output without having to make extra passes through the result set. The remaining proposals on my user page might be interesting for someone to look at, but they are either too vague or overlap with existing proposals for really serious consideration and I plan on merging them with the appropriate RFC’s soon. Definitely appreciate any comments/questions! Owen (@Wikia) _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
