Since PaulGregory refuses to play his usual role to be the sceptical, someone had to jump in:
Probably.
MODX Staff
Maybe Paul is beginning to see my vision in a little more detail.
Since PaulGregory refuses to play his usual role to be the sceptical, someone had to jump in:
I argue that this majestic plan results in re-inventing the OO-concept for web-applications, or even the way PHP works. (I prefer to talk about "applications" than "sites", because I think that’s where "the music will play" - as we say in German ;-) )
It’s taken about a year, but I’ve rewritten the core three times, once using Propel, the second time using xPDO after I invented it, and most recently to create the stepping stone release between the current MODx and the significant data structure changes of the 1.0 (a.k.a. Tattoo) model. All are based on my research into a variety of PHP frameworks that are claiming to be like RoR or other prominent open source Java projects like Apache Struts or Apache Turbine, etc. And as you might expect, they are all hung up in the paradigm shift from run-time to build-time configuration, which is a significant attribute of RoR and the current Java landscape, and one I don’t necessarily agree fits in the PHP world, despite the best efforts to turn PHP into Java. Build-time configuration is fine for developers, but as a web site/application life-cycle management application, MODx should enable RAD (Rapid Application Development) without the mess of dealing with command-line build scripts.
And the plan is great - but I would estimate that it will require far more than 1000 days of work- and it will - like all projects of that scale - suffer some "infancy-illnesses" and, as such, could be far too big to handle for an opensource project of the category that MODx actually belongs to.
In detail I would be interested in a comparision of Tattoo with similar "architectional" efforts like RubyOnRails and how well it does fit to the current activities of the PHP-dev community.
Manager pages can be built in the same way as the front-end.
once 0.9.5 is released, I’ll be preparing the team to start working with the new core and getting the manager converted.
I’ve understood it in this way. Basically, the difference between "front-" and "backend" will turn out to be more and more superfluous. This will become more a kind of "more-or-less" than "either-or".
Does this mean that it will be possible to build different manager profiles (I mean different contents and presentation) for specific solutions and user groups? I think about a separate manager for editors, and a different one for help desk staff, for example.
MODX Staff
Absolutely, almost complete customization of the manager will be possible, though some things are sacred, and the distributed management interface will still be file-based, and not editable by itself... :/ that would be just a little wierd...
Quote from: OpenGeek at Nov 07, 2006, 03:28 PM
Manager pages can be built in the same way as the front-end.
Does this mean that it will be possible to build different manager profiles (I mean different contents and presentation) for specific solutions and user groups? I think about a separate manager for editors, and a different one for help desk staff, for example.
once 0.9.5 is released, I’ll be preparing the team to start working with the new core and getting the manager converted.
Right; we haven’t decided on the final architecture or file structure for the manager, but I think our goals are in line, because we definitely want to make it so you can override and not have to hack the core files at each upgrade.
MODX Staff
MODX Staff
No, it wouldn’t impose anything. It would just be offering options and additional flexibility in how you organize your code and markup and such. We will have native versioning, rollbacks, and archiving, separate from SVN type functionality, and accessing database managed content does not exclude it from being treated like content from a file system; FTP, WebDAV, and other protocol access to MODx managed content, regardless if it’s stored physically in a db or on the file system or on Amazon S3, is the direction I’m envisioning.
That would impose the use of file-based templates, which IMO is better that using chunks from database. Using file templates has many advantages:
- they are easy to create and modify (after all they are plain text),
- they can be edited with external editors, which itself is an advantage,
- they are easily portable and backupable - zip, move, unzip is all that has to be done,
- they may be tied to the source versioning system e.g. Subversion.
No, it wouldn’t impose anything. It would just be offering options and additional flexibility in how you organize your code and markup and such. We will have native versioning, rollbacks, and archiving, separate from SVN type functionality, and accessing database managed content does not exclude it from being treated like content from a file system; FTP, WebDAV, and other protocol access to MODx managed content, regardless if it’s stored physically in a db or on the file system or on Amazon S3, is the direction I’m envisioning.
