Quote from: olafmol at Apr 22, 2007, 03:17 PM
maybe i don’t understand it all to well, but isn’t xPDO mainly aimed at database-transactions and having data-objects, and are frameworks like cakePHP and code igniter much more extensive?
Well, xPDO is an object-relational bridge, which will allow you to write applications that are portable to (and optionally optimized for) any relational database engine. It focuses on one general area that is or will soon be covered by CI (Active Record, OR/M, database abstraction).
The code xPDO generates for you represents a model in a typical MVC framework, and provides both a way to interact with the persistent data of an application, as well as a domain model that represents a baseline API (i.e. scaffolding) for interacting with the application data. This scaffolding can then be used for quick and dirty access to that relational data in an object oriented way, and/or quickly extended with domain logic (i.e. business logic, business rules) to provide a complete, robust model which MODx, or any "reasonably well designed PHP application"
1 can utilize to access, interact with, integrate with, or extend your application.
Other than the obvious benefits of a database abstraction layer, the real benefit of xPDO IMHO is the balance I’ve been striving for between maintainability and optimization. For instance, the ability to change the application over it’s life-cycle without forcing add-ons, integrations, and extensions to be rewritten everytime (i.e. when SQL statements have to be updated because database table structures are modified) is a key factor as I’ve been re-building MODx with xPDO itself. But the existing solutions I found did not factor performance into the equation enough, because database performance can quickly become the primary scalability bottleneck for any PHP application. That point and having the ability to support PHP 4 for a bit longer were the deciding factors when I chose to reinvent the PHP OR/M wheel with xPDO just over a year ago.
1 - A "reasonably well designed PHP application" refers to one written with portability, integration, and respect for PHP’s single global namespace in mind.
Quote from: yehosef at Apr 24, 2007, 02:35 PM
The project I am working on is using these two tools (modx and CI) and each have their strong points. But after having developed an application in CI and having developed a simple view in modx (taking the database for a online catalog and displaying all the components - accessories, swatches, etc.) It’s clear that there are some big pieces missing for me to use modx more for applications (and like it).
The biggest piece I need is a powerful templating/view system - php is fine and/or a way to pass complex data (assoc arrays/objects) to the view. if I have a <ul> list of elements, I shouldn’t have to make that html in my snippet (Even with chunks - if I have 15 different components - how many chunks do I have to have - just for one page - when I go do all the same logic with one page of php and some associative arrays/objects) If anyone can explain how I could do this in modx I would be grateful.
The new object-oriented, xPDO-powered core will be introducing some very cool ways to deal with complex data in your MODx views, as well as more flexibility in templating, including allowing traditional PHP files to be easily included, and allowing alternate templating engines to handle all or part of your content. For now, you can easily include traditional PHP files by creating a snippet that includes that file within an output buffer and returns the output.
See code in this post for an example of how to use traditional PHP files as MODx Templates; this would work equally as well for snippets...
MODX Staff
☆ A M B ☆
