Jump to content
MakeWebGames

Whitespace

Members
  • Posts

    3
  • Joined

  • Last visited

Everything posted by Whitespace

  1. This isn't necessarily true. There is an entire class dedicated to a User; its intention is to provide passed information to completely map the object to the class and pass the object to a separate (Validation) class, and so on... To simply put it, we want to play with the object rather create one to have it on display. You can of course do this but this can be accomplished more simply. You can indeed argue that you can always treat the user as an object (or for a majority of the time), which can indeed beneficial, however you don't have to. Also, the calling of Use_get.. is handled by globals, which is handled by another, and so on... Essentially you revolve around independent files for different purpose without interacting with other important files (which you can also do).   User_get_info simply returns information to be displayed or handled, which (can) be passed on to a class - such as Users. This saves you the reverse process (e.g. having a completely defined objected rather than an object searching itself).
  2. This particular example isn't OOP, but rather a simple and brief example of how the functionality of MCC can be improved. In addition, procedural programming makes the process much easier than requiring an entire class and additional lines of code. In addition, the function (User_ge...) is one time database query, which fit into the one of the listed problems I mentioned before. If you have any more questions please feel free to ask.
  3. Runn is like MCCv2 but less ugly and actually OO. That's all... Over the next few weeks I will occasionally provide examples of the functionality of the and address issues MCC had which Runn will address. Example 1: The user's information MCC functions around globals.php which pulls functions and database queries. This is more often used to call the user's information, such as their id, username, money, etc. This method of calling the user's information can be very useful, however, issues do occur from this methodology:   Irrelevant information for the current script/Unnecessary amount of database queries The information will more than often be static The script itself may not require any user information   One primitive example of this is the user's information on the left panel of MCC. To resolve this issue we can take advantage of sessions. Firstly, if we successfully authenticate a user's information before proceeding to login we can create a $_SESSION element and set it to be true.   $_SESSION['user_update'] = 1;   This array element is important as the information will be assessed by an if statement.   if ($_SESSION['user_update']) { $_SESSION['user'] = User_get_info( 'user_id', 'user_display_name', 'user_money', 'user_crystal', 'user_level', 'user_will', 'user_energy', 'user_health', 'user_brave', $_SESSION['user_id'] ); $_SESSION['user_update'] = 0; }   Now a developer can simply use the already provided information without needing to hit the database. Runn runs its own globals file and will check the state of the session. Though we have to remember to include update the session's when we change the (relevant) information about the user we've simplified the process and save ourself time debugging as we're only using one function and one file, rather than numerous files and functions. This was brief example of what Runn will be capable of.
×
×
  • Create New...