Hi,
First a little background: I was looking for a CMS application and after considering and testing a number of them that I rejected for various reasons, I fumbled upon MODx which, as far as I’m concerned is a winner, most notably for its modularity and caching scheme. I almost immediately started working on integrating phpBB (forums) through snippets, which is underway. Please note I’m completely new to both MODx and php, so it’s quite possible I’m confused.
The problem
- php seems to have no namespaces. Functions, classes, and global variables all lie in the global namespace (doh).
- MODx embeds external plugins and snippets of code, that are also using the global namespace.
- Name clashes ensues.
Now, that might not be such a problem for custom php code specifically written for MODx, after all, simply renaming conflicting entries in the global namespace solves the issue, however, it becomes a pain if, as I did, you make use of external code (such as libraries), in my case phpBB stuff included from MODx snippets. In that situation renaming involves : a) potentially breaking compatibility (with extensions to phpBB in my case), and b) being forced to redo the renaming job with every update.
The same naming issue also potentially exist with/between community made snippets, plugins or modules.
I imagine my situation is rather unusual, however, I expect it’s not unique, or won’t be if MODx grows a large user base.
Anyway, just like SQL tables, I’d like to suggest making systematic use of prefixes in the global php namespace, both in MODx code, and custom snippets/plugins/modules, to avoid potential name conflicts down the road (a good practice for any php code made public in my opinion).
Any thought appreciated.
PS: Actual conflict I ran into was because of a "class template" in Ditto. Fortunately, the snippet I’m writing being relatively similar in use to Ditto (as a content aggregator for news/pseudo blogging), I shouldn’t have to run the two on the same pages.
That’s right PHP has no namespaces so the prefix-naming scheme you suggests seems like a good idea. Now I’m not part of the MODx-dev team, but I have done quite a bit of development, so I can see that the things you mentions might be a problem further down the road unless precautions are taken. BTW MODx rocks, I’m already using it when I’m developing small-medium sized sites for my clients.
