re-use and move toward an easy MVC design, where the models are handled by ORM, the controllers are either Actions or SpecialPages, and the views are handled by Skin/Message/HTMLForm. And while ORMTable and FormAction, etc. are not used everywhere in the code, I believe this is a good direction to move in, primarily because it makes everything easier on developers. For example, I am making an extension for SSL authentication (because the current one is pretty dated), and I used FormSpecialPage with ORM to make the entire extension, and development was so easy it was beautiful. What would have otherwise been implemented using custom DatabaseBase calls and random functions is now made vastly simpler with standard interfaces. Also, I believe in MediaWiki's case ORM is the right way to go rather than the alternative raw SQL method. I say this because the primary reason people argue against ORM is because you have more freedom over the database and can focus on the data rather than the functionality. In MediaWiki, because of various compatibility reasons, there's only so much SQL we can use. For example, stored procedures are thrown out the window because Sqlite doesn't support them. Because of this limitation, the usual disadvantages of ORM do not apply. And while I'm sure an argument could still be made against ORM, I think the arguments in favor are a lot stronger. On that note, I'd just like to say that our ORM interfaces still have room for improvement. It would be good to have ORM handle instantiation of various internal types without bothering the end developer about it. For example, if ORMRow could automatically make User objects or Revision objects, etc from a row result where the indicated field is a reference to such an object. Also, there are weird quirks, such as the fact that ORMRow forces you to have an "id" field in your table, even if that doesn't necessarily apply to the model you are developing. Another quirk is the fact that fallbacks don't exist. The User object, for example, will try and load from the database or session, but if it doesn't find anything, it will default to an anonymous user. ORMTable, however, will return false when calling selectRow() rather than creating a default object, forcing the outer layers of code to load defaults manually. The easy way to fix this would be to change loadFields() so that rather than use the ID, just use any indexed fields in the object to load the fields. That way you can use newRow() to load defaults and then call loadFields() in an attempt to get from the database. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com On Mon, Aug 27, 2012 at 4:53 PM, Chad <innocentkiller(a)gmail.com> wrote:

Le 27/08/12 22:53, Chad wrote: I originally thought we should reuse an existing ORM engine, Jeroen eventually convinced me his code would be easier to maintain for us. He wrote ton of online documentation on mediawiki.org. ORM would make our code hopefully a bit more concise and avoid us to duplicate logic in all our classes. We can do the migration as we usually do, by slowly refactoring our code over several releases. -- Antoine "hashar" Musso