On Tue, Aug 28, 2012 at 12:12 AM, Aaron Schulz aschulz4...@gmail.com wrote:
The idea of some base classes for CRUD and API/Pager table listings is fine.
It can obviously avoid inconsistency among the DAOs. If these classes are
called ORM*, I guess that's OK too, as longs as they don't scope
Hi,
It's recently come up in some of the Wikidata changes proposed to core to
start using some ORM-like interfaces for accessing this data[0]. Since we
don't use ORM-style access anywhere else in core, I figured it warranted
some wider discussion before we begin introducing the pattern.
From what I can tell, MediaWiki is trying more and more to reduce code
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
Hey,
I'm a big fan of the pattern (or at least parts of it), which is the reason
I spend quite some effort getting a generic interface into MediaWiki. This
is the ORMTable class mentioned by Tyler. Documentation of this class,
together with a rationale and some implementation notes can be found
Le 27/08/12 22:53, Chad wrote:
It's recently come up in some of the Wikidata changes proposed to core to
start using some ORM-like interfaces for accessing this data[0]. Since we
don't use ORM-style access anywhere else in core, I figured it warranted
some wider discussion before we begin
On 08/27/2012 04:53 PM, Chad wrote:
Hi,
It's recently come up in some of the Wikidata changes proposed to core to
start using some ORM-like interfaces for accessing this data[0]. Since we
don't use ORM-style access anywhere else in core, I figured it warranted
some wider discussion before we
There are some examples linked from the documentation here:
https://www.mediawiki.org/wiki/Help:ORMTable
Note that these are not clean examples as they contain unrelated code as
well.
And of course this is just one example of how you can go about implementing
an ORM pattern, while this tread is
I was just looking through those classes again.
I think ORMRow is generally OK, since it's mostly a simple CRUD wrapper to
deal with some of the busy-work of making data access objects. I don't
really get the summary (updateSummaries/inSummaryMode) stuff though. I
guess the callers/subclasses do
