future-proofing apps developed on current framework

Hi,
I am in the preliminary stage of designing a new way for myself to roll out the web apps that my clients ask me to create.
MODx is going to play a large roll.
I’m highly interested in modularity, reuse etc, of course, but also want to build a very consistent methodology for implementation and QA. There will also be a lot of tying MODx to legacy web apps (not replacing, not porting..)
I was just reading this thread http://modxcms.com/forums/index.php/topic,8459.msg59671.html#msg59671 where Ryan says:

There’s been lots of inquiries like this, but it doesn’t exist right now natively in MODx. Lots of solutions can be made to work once you become intimately familiar with MODx, but the development pace is pretty interesting lately and the stuff that applies today might not in the future. Best of luck!

My question then is this - should I dive in and start learning how to code with this API? Will my apps be forward-compatible.. or if that’s a loaded question, is there anything I can do, or any things to keep in mind while I plan a system that might start to come to life 3 to 4 months from now?

Thanks everyone for such great work. I look forward to when I will be giving back to the project.

I say if you need the apps now, code them now with the current API. "The future" and forward compatibility are promised to no one as the saying goes. It is, however, a pretty safe bet that becoming familiar with the current API will present itself as a tremendous resource. If the core of what is MODx completely changes, it is still MODx and based on MODx, so at the very least, you soften the blow of the learning curve.

-sD-

Thanks for your thoughts sD. Makes sense to me.

Also, I just noticed that OpenGeek said this in another thread recently:

in fact, there will be an official release of a complete object-oriented API (similar to this) for all of MODx 0.9.x. It is being built on top of the new xPDO project I am working on, and will serve as both an alternative API for use with your existing MODx, and as a preview of what 1.0 will be utilizing to take the MODx framework to the next level

If there is anything practical I can say about how to future-proof your MODx creations, I would suggest the following:
[*] Isolate anything that is dependent on custom SQL you author; put it in a class, a separate include of functions, etc. This will be the greatest point of change moving forward, as we abstract MODx away from MySQL, allowing it to work on any database platform PHP can connect to.¹
[*] Anything you do repetitively, isolate into classes and/or functions you keep in external files. These can easily be incorporated now as well as the near future, and this will also insure you only have to change code in one place to upgrade when a major core change affects your code.
[*] Don’t add or change core tables; add a table that aggregates an existing core table with alternate or additional data. This way, when core structures change, you can much more easily manage that change in your isolated data structure and related code.
[*] Don’t panic. In most cases, the new object-oriented API’s I’m describing will be available without sacrificing any of the existing API. In most cases, the existing API methods are just reimplemented using the new API, for backwards compatibility.² And as is proper with any framework, any public API methods that are going to be removed will be deprecated first, so you have a release or two to make the necessary adjustments.
[*] If you are going to do a lot of database-dependent web application work, I highly recommend taking a look at and/or talking to me about xPDO and what it can do for you now, and/or in the near future. It’s just my attempt at an object/relational mapping and data access tool that I believe fits the realities of the current PHP world better than any existing solution I’ve tried. I have not had time to document everything it can do so far, but my use and refinement of it over the past 8 months has not dissipated my confidence in it’s power and potential.
[*] I have client sites running in the new MODx core powered by xPDO and had to do little, if anything to them to make them work following an upgrade from 0.9.2.1 or 0.9.5 beta release. Until we get to 1.0, where some signficant database structure changes will be introduced to the MODx core, there really is little to worry about; and you’ll have plenty of time to convert to the new API’s before that happens...


¹ - Future releases of MODx will take advantage of PDO, the new standard db access layer in PHP 5.1+.
² - In fact, much of the legacy compatibility in the new core is implemented as an example of how to extend the functionality of the new core.

I think I’m beginning to get a glimmer of what this can do. Reading the php.net docs on pdo, I see that it can emulate prepared statements, thus making it possible to use the same queries repeatedly without the sql engine having to go through the whole routine of parsing and optimizing the query as if it’s never seen it before... sort of a query cache. I can see where this could make a big difference, say in a menu snippet where recursive queries can be repeated dozens of times. Or even in the parser, where for every page it basically makes the same queries, just with a different ID. Am I on the right track here?

Quote from: OpenGeek at Oct 31, 2006, 01:12 AM

If there is anything practical I can say about how to future-proof your MODx creations, I would suggest the following:

Perhaps you should add this post to wiki HOWTOs?

Just spoke to him on IRC, and I’m going to add this page. I agree, it would be good there.