As is, this is not scalable which was my claim way back before any code was even provided but I had different reasons then.
And again when people say "not scalable" I genuinely have no clue what they're talking about, as if they're just looking for problems that don't exist or fail to understand how to scale for performance; much less how to use actual design patterns that fit the data instead of shoe-horning a single design model into doing everything whether it fits or not.
The very thing I've seen client after client the past decade.
However, it does introduce a real scalability and complexity problem because so many files are required for a particular section such as users CRUD.
Which do you want? Separation of concerns with efficiency of load, or single massive files that are impossible to maintain that waste time with dead code.
.process.php -- does the data handling, may pass off to another for sub-functions.
.content.php -- outputs the result
Thus that user admin panel gets:
/actions/admin/pages/users
users.controls.ini.php 24 B
users.create.content.php 325 B
users.create.process.php 1222 B
users.createSuccess.content.php 284 B
users.delete.process.php 646 B
users.deleteFailed.content.php 276 B
users.deleteSuccess.content.php 278 B
users.edit.content.php 266 B
users.edit.process.php 1734 B
users.editSuccess.content.php 279 B
users.list.content.php 200 B
users.list.process.php 341 B
users.process.php 462 B
The direct users.process.php determines which of the sub processes to load and run. One .process.php each for create, delete, edit, and list. Extra .content.php for things like success/fail. It's not rocket science, and we're not pissing all over memory loading the create/delete/list when all we want to do is edit!
Where's the "complexity" of that? That's as simple as it gets!
