I won't argue with Stephen, even though I could. ;)
Basically, if you want to go with MVC on your own, you'll need at least a request dispatcher and probably a view resolver along with some configuration facilities.
As procedural PHP has no real support for types, coupling problems will probably be a PITA.
In a most basic scenario you could just have a request mapping like
$mapping = array(
"show_profile" => "profile.php:showProfile",
"edit_profile" => "profile.php:editProfile",
"etc" => "whatever.php:doEtc"
);
and then just retrieve the correct setting and explode it to $fileToInclude and $functionToCall. There you'll have your controller-problem sorted out (passing some generalized $request parameter to them or so).
As for a very simple run, your controller could do whatever it should and then explicitly inlcude the view file or return some data so that the view resolver can be invoked with the identifier (e.g. file path or mapping key) of the view to render and the data to display.
There are serveral approaches, and the above one is not even close to an elegant solution (heck, we're talking about procedural code :D) but this is the most simple clean-ish variation I can think of; you can extend on it as you please.
Keep in mind that you want to keep your code as decopuled and maintainable as possible.
(A hard way would be to create a framework with which you could use arbitrary code as controller with arbitrary functions and parameters; the easiest one is simply a matter of some explicit includes)
PS.: I'd suggest using existing frameworks for that matter, but the only publicly available PHP frameworks that are viable are all OO and mixing up OOP with procedural code would be a terrible practice; even worse than reinventing your wheels. Actually, if you don't have to stay procedural at all cost, you better switch to OO.
Good luck with your project!
Since C is statically typed and JSON is not, and any JSON element can be a null, a number, a string, a boolean, an object, or an array, you basically have to do it as "a rip off the OOP way". Create a record type that represents a JSON value, and has a member that's a tag indicating which type of JSON value it is, and then create "subclasses" that build on this record type. To represent JSON well in C, you basically have to recreate OOP and polymorphism.
Anything that uses a JSON value will have to take a pointer to the base record type. Remember that objects are always reference types, poor C++ language design choices notwithstanding, because otherwise it screws up polymorphism, and you require polymorphism to do this right. When you find out what kind of "subclass" you're actually working with, (by checking the tag member,) you can cast your JSON Value pointer to the appropriate subclass type pointer to access the rest of the record.
Best Answer
A lot of procedural code is very OOP-like. Basically, instead of
object.function(params)
, you dofunction(object, params)
. You can group your files accordingly.However, what a lot of long-time OOP programmers don't realize is how limiting it is that a function must belong to one and only one class, and that all such functions must be grouped into one file accordingly. Procedural-style allows for many other kinds of groupings that often fit better under certain circumstances:
engines
andtransmissions
.cars
.steer()
for different kinds ofvehicles
could all be grouped into one file.parts
and return acar
.Basically, all those times you couldn't really figure out which class is the best fit for something, in procedural that's not really an issue. Don't get me wrong, the way OOP groups functions is successful because it's a very reasonable default. That doesn't make it the best grouping under all circumstances, though.