Maybe we should release 0.9.7 instead

Quote from: PaulGregory at Sep 06, 2006, 05:09 PM

Last word from me on the API thing is to highlight this part of the Wikipedia definition: that a computer system, library or application provides in order to allow requests for services to be made of it. API infers officialness and completeness, not a reverse-engineered interoperability aid.

Though I do agree with those inferences made by saying API, it still is an interface into those services, be they official, complete, or not. It’s just totally dependent on the audience of your API (i.e. core app developer vs. add-on developer), and the context of how you use the xPDO tool against a particular data source. In other words, the MODx object model I created with xPDO is targeted to become official and will soon be a complete public API to MODx; I used xPDO to jumpstart the process by providing me with a complete persistence layer. But the lesser models I created as interfaces for working with data from MD-Pro, PostCalendar, or SlideShowPro might not be official or complete, or meant to replace the app’s API itself; I just created them to make it easy to work with specific pieces of data I wanted to present with MODx, or to import data from an external set of data tables to a relevant MODx table, or set of tables, using a consistent, and familiar approach. An alternate API if you will. Whether it is limited to the purpose of interacting with the database, or you extend it to include business logic and make a "complete" solution out of it, I still think it’s semantically accurate to refer to it as an API.

But, maybe I can just avoid end-user confusion and developer debate, by referring to the xPDO-generated classes and files in general as an object model, which may not imply so much officialness or completeness in every situation, nor does it limit them to that purpose. Of course, the whole Zappy (xAPI) thing is a very cool idea, and gets across the message of being able to quickly create a simple interface into a data source. Hmmm, anyway, food for thought...

Just an update on 0.9.7 in my opengeek branch -- I have the installer and cache refresh mechanisms updated and working now, so you should be able to export from SVN and run the installer as you are used to so you can try out the branch. There’s still lots of work to do, including some significant optimization I’ve identified after some profiling, getting some of the latest work merged in, and lots more testing/tweaking on various versions of PHP 4.3.x and 4.4.x.

One note on refreshing the new cache; this is not yet working in an optimal way and is simply removing all cache files and attempting to rewrite the config and context files, and this will most likely happen on each save of content, a snippet/plugin or other resource, etc. until I complete some work I’m doing on restructuring the cache directories/files into a more efficient design. At that point, a much more granular approach to updating cache items will be available.

P.S. I’m also working on generic object caching for xPDO as well, so at some point soon, MODx will automatically be able to utilize this caching mechanism to further improve performance as well.

P.S.S That also reminds me of another benefit of the new architecture, which is a much better ability to make use of opcode caching techniques on the server (e.g. keeping classes loaded server side between requests so they don’t have to be included each time).

Keep up the awesome work Jason. Sounds like we’re a relatively small bit of caching work away from a test build.

Awesome is the word, to the layman that I am, it seems like pure magic
But even if I don’t get the method, I think I get the concept... and it’s really exciting !

I have the installer and cache refresh mechanisms updated and working now, so you should be able to export from SVN and run the installer as you are used to so you can try out the branch.

Jason, I exported the branch and ran the install (which went okay) - but I can’t get anything to be displayed after that. Both the site URL and Manager URL display a blank page.

I traced the process through for the main site initialisation and found that it doesn’t like this line in modcachemanager.class.php:


It looks like it is trying to reference the getMany method of the modcontext class and there isn’t that method available in the class when I looked. But, that is about as far as I’ve got (still finding my way around the code here so I could be wrong on this one)

Any ideas?

I’m running PHP 5.1.4, Apache 2, MySQL 5.0.19 on MAMP.

Yep, just remove the & and all should be fine. I’ll correct this in SVN.

Doh! Actually, I thought you were running PHP 4 for a second -- I forgot to add that table to the installer. Put this PHP script in a file and execute it from the root of your site to create the missing table...



replacing the appropriate db connection stuff, and that should create the table and make the error go away; strange that I didn’t encounter this when I installed from scratch, hmmmm...anyway, I’ll update the installer...sorry...

Just FYI, getMany is part of xPDOObject, which is the base class for all the db objects in xPDO. So all objects will have the getMany() method, as well as get(), set(), getOne(), getMany(), addOne(), addMany(), etc.

And what’s really odd is I never had that table (modx_context_setting) created on any of the test systems I was working with, but I haven’t ventured past 5.1.1, so I’ll bet I need to specifically set the error handling for PDO (the default may have changed in these latest versions). What’s supposed to happen is the error should be ignored at that point (i.e. getMany(’modContextSetting’) would just return null). xPDO automatically creates the table on demand whenever an insert operation is attempted (i.e. save() called) and fails with an error code indicating the table doesn’t exist.

I’ll do some more research into it.

I just found the problem ... I had eAccelerator enabled on my MAMP install which was screwing it up somewhere along the line. Turned that off and it works fine on PHP5.1.4 (also tested on PHP4.4).

Quote from: garryn at Sep 07, 2006, 07:09 PM

I just found the problem ... I had eAccelerator enabled on my MAMP install which was screwing it up somewhere along the line. Turned that off and it works fine on PHP5.1.4 (also tested on PHP4.4).

Great news Garryn -- I was just reading about eAccelerator and all the problems past 5.1.1...

I think something is not processing properly with plugins; they are executing, but something’s not right. Hopefully, I’ll have some fixes for that by morning.

Great news guys but can we get settled on what we are going to release?

First there was version 1.0 then 0.9.5, then 0.9.7 and now I’m hearing of 0.9.8, and a possible 2.0

Anyway it would be good to have serveral options to choose from.