Quote from: davidm at Sep 06, 2006, 01:11 PM
Let me drop a line into this fascinating (yet sometimes hard to grasp), debate.
I better be clear about what an API is, since I am no programmer, and I am communicating quite a bit about MODx... so far, I have referred to WikiPedia’s definition : http://en.wikipedia.org/wiki/Application_programming_interface
Short : An application programming interface (API) is the interface that a computer system, library or application provides in order to allow requests for services to be made of it by other computer programs, and/or to allow data to be exchanged between them.
Does that seem acceptable to you guys ?
So far I have mentionned the MODx API and dbAPI as it is on the main modxcms.com website...
what’s the guideline here (except, don’t talk about what you don’t know 
) ?
Yes, the WikiPedia definition is good; though I would stress that typically, an API is more specifically referring to the public interfaces (or functions) of a library or application which the developer expects users to stick to when using the library or writing additional code for the application.
And in terms of xPDO, it’s essentially a tool with which you can quickly build custom libraries that are, simple, out-of-the-box API’s into any data model. These API’s consist of the core CRUD logic, the xPDO extensions logic, plus whatever additional logic you add to the generated code, which in most cases, from my experience using this tool over the last 6 months in various stages of development, is usually very little.
As for MODx API and dbAPI, we need to be careful; an API in a framework is of utmost importance. To me, an API is the primary public interaction point with an application or product. Moving forward, the MODx API will be one consistent set of classes and methods that will be used to interact in any official way with the core. This will help make maintenance of and extensions to the core much easier to accomplish (i.e. code that does essentially the same thing isn’t spread out illogically all over the filesystem, as it is currently).
The dbAPI is a special case, however. Since the main class of the proposed 0.9.7 MODx release is an extension of PDO, which is in itself a database API, the dbAPI is now redundant and will be kept around only to support legacy components and to serve as an alternative, slightly more abstract API that simply wraps the PDO methods which are part of MODx. For instance, $modx->db->query("SELECT * FROM foo") can now be written as $modx->query("SELECT * FROM foo") and the implementation of $modx->db->query() will be refactored to simply use the $modx->query() method, rather than it’s own implementation using the mysql extensions. In a sense, it just becomes an API which wraps the PDO db methods.
Quote from: rthrash at Sep 06, 2006, 02:15 PM
Jason, just to clarify, won’t it become relatively easy to rewrite the manager using the built-in API of MODx with your core? If so, we can probably cut down quite a bit on the filesize.
Absolutely; I’ll try and provide some examples of exactly how to go about this as I start going through the manager to link up my new caching system. Obviously, once we start working on this, it will be essential to replace any calls directly to the mysql db extensions throughout the manager in order to prepare for releasing MODx for PostgreSQL or SQLite, etc. I’ll also try to start talking about what can go away and what will need to stay for this release plan over the next couple of days.
BTW, for those of you curious about the xPDO-powered code, I’ve checked in my current progress to the branch called
opengeek in SVN. This does not yet work out of the box or following an installation, but you can review the new file structure (see /core/) and the xPDO-based API (located at /core/xpdo/om/modx095/), and I should have it installable and testable within the next 24 to 48 hrs.
MODX Staff
MODX Staff
MODX Staff
