Code Refactoring Underway
[RSS]
"The rumors of my death have been greatly exaggerated." While progress has been slow, we haven't given up on PBW2!
For let's say, the last year or so, we here at Fyron HQ have been slowly hacking away at the underlying framework of PBW2. While the initial code design was a great learning experience, many less than optimal choices were made along the way.
One key problem is that I only set up controller classes for the first part of a section's URL. Looking at the detail page for an individual object is an action in that controller. All typeso of interactions with that object are also actions in the same controller. The games controller, for example, ended up with 26 actions, and 3968 lines of code! Trying to force a more restful API on top of the heavy controller classes last year really brought this to a head.
A second problem with PBW2 is the general weight of controller actions. The model design used is a basic extension of Zend_Db_Table_Abstract. These models are responsible for writing data to the MySQL database, and that's about it. The rest of the business logic a controller needs to execute its task is generally handled within the controller action itself. This tight coupling of business logic inside controller actions makes it difficult to reuse elsewhere, such as a set of API controllers.
Part of this is being solved by moving ancillary actions that need to be performed into the new ORM classes. When a game is created, a corresponding forum category also has to be created. Currently, this is done sequentially within the game controller's create action. Going forward, creating the forum will be handled inside the game ORM class in an "afterSave()" callback method. This more cleanly encapsulates the actions that need to be taken every time a game is created, allowing it to be done without duplicating code by other classes than the game controller itself.
To make PBW2 leaner and easier to enhance, I've been working on the following goals:
* Refactor all controllers into Zend modules. Module design will follow a somewhat restful approach. The base url for a section (e.g. news, games) will map to an Index controller that handles actions relating to the entire collection of content. Each descending type of content object within a module section will have its own controller (e.g. forums section will have a controller for categories, a controller for threads, and a controller for posts). All interactions with a particular type of object will be handled in actions of the respective controllers.
* Standardize controller actions across content types. Since each content type now gets its own noun-based controller, there is no reason to continue having a "playereditAction" method. Wherever possible, every item controller implements "indexAction", "createAction", "editAction", and "deleteAction". When I get started on the API, this will make it easier to map HTTP request types on noun-based URLs to underlying controllers.
* Replace model classes extending Zend_Db_Table_Abstract with custom Object Relational Mapper (ORM) classes. This replaces a large number of custom function names across content types with a small, predictable set of methods. Complex join queries that were used to retrieve both the data for a game, its host, the mod used, and so on, are getting replaced with cached, on-demand lookups based on relationship properties. For example, a $game entity object exists to represent each game on PBW2. Each $game has a $user property, which is itself an entity object representing the user that is hosting the game.
* Standardize partial view script naming conventions. When a list of objects needs to be rendered, the parent view should call a partial inside a "list" folder. That list partial should subsequently pass each object into a partial inside an "item" folder. This more unified naming structure makes the view scripts more predictable, reducing the time it takes to debug them and extend them in the future.
When will all of this be done, you might ask? Unmanaged programmers can't answer such silly questions! I can tell you, however, that the ORM portion is completed. Migrating all of the site sections into refactored Zend modules is progressing nicely. The Forum, Mod, News, Shipset, Support, and User sections have been completely refactored.
The Game section is about 20% done. So far, just the basic listing controller and the game item create/edit/delete controller have been completed. Work on the game section is slower, since I am also trying to move all of the file manipulation code into separate library classes. The Game section is the most complex part of the whole system, and will require some time to regression test.
When all is said and done, I will bring back the "beta" subdomain with all of this refactored code, and be looking for a few intrepid volunteers!
For let's say, the last year or so, we here at Fyron HQ have been slowly hacking away at the underlying framework of PBW2. While the initial code design was a great learning experience, many less than optimal choices were made along the way.
One key problem is that I only set up controller classes for the first part of a section's URL. Looking at the detail page for an individual object is an action in that controller. All typeso of interactions with that object are also actions in the same controller. The games controller, for example, ended up with 26 actions, and 3968 lines of code! Trying to force a more restful API on top of the heavy controller classes last year really brought this to a head.
A second problem with PBW2 is the general weight of controller actions. The model design used is a basic extension of Zend_Db_Table_Abstract. These models are responsible for writing data to the MySQL database, and that's about it. The rest of the business logic a controller needs to execute its task is generally handled within the controller action itself. This tight coupling of business logic inside controller actions makes it difficult to reuse elsewhere, such as a set of API controllers.
Part of this is being solved by moving ancillary actions that need to be performed into the new ORM classes. When a game is created, a corresponding forum category also has to be created. Currently, this is done sequentially within the game controller's create action. Going forward, creating the forum will be handled inside the game ORM class in an "afterSave()" callback method. This more cleanly encapsulates the actions that need to be taken every time a game is created, allowing it to be done without duplicating code by other classes than the game controller itself.
To make PBW2 leaner and easier to enhance, I've been working on the following goals:
* Refactor all controllers into Zend modules. Module design will follow a somewhat restful approach. The base url for a section (e.g. news, games) will map to an Index controller that handles actions relating to the entire collection of content. Each descending type of content object within a module section will have its own controller (e.g. forums section will have a controller for categories, a controller for threads, and a controller for posts). All interactions with a particular type of object will be handled in actions of the respective controllers.
* Standardize controller actions across content types. Since each content type now gets its own noun-based controller, there is no reason to continue having a "playereditAction" method. Wherever possible, every item controller implements "indexAction", "createAction", "editAction", and "deleteAction". When I get started on the API, this will make it easier to map HTTP request types on noun-based URLs to underlying controllers.
* Replace model classes extending Zend_Db_Table_Abstract with custom Object Relational Mapper (ORM) classes. This replaces a large number of custom function names across content types with a small, predictable set of methods. Complex join queries that were used to retrieve both the data for a game, its host, the mod used, and so on, are getting replaced with cached, on-demand lookups based on relationship properties. For example, a $game entity object exists to represent each game on PBW2. Each $game has a $user property, which is itself an entity object representing the user that is hosting the game.
* Standardize partial view script naming conventions. When a list of objects needs to be rendered, the parent view should call a partial inside a "list" folder. That list partial should subsequently pass each object into a partial inside an "item" folder. This more unified naming structure makes the view scripts more predictable, reducing the time it takes to debug them and extend them in the future.
When will all of this be done, you might ask? Unmanaged programmers can't answer such silly questions! I can tell you, however, that the ORM portion is completed. Migrating all of the site sections into refactored Zend modules is progressing nicely. The Forum, Mod, News, Shipset, Support, and User sections have been completely refactored.
The Game section is about 20% done. So far, just the basic listing controller and the game item create/edit/delete controller have been completed. Work on the game section is slower, since I am also trying to move all of the file manipulation code into separate library classes. The Game section is the most complex part of the whole system, and will require some time to regression test.
When all is said and done, I will bring back the "beta" subdomain with all of this refactored code, and be looking for a few intrepid volunteers!
Comments
[ Post comment ]
Speaking of the beta subdomain, you still have "beta" up there on the header... are you emulating Gmail now? :)
And I hope that the upcoming beta of the new code won't require a completely new database? So if you host a game on the regular site, players can access it from the beta site, and vice versa? And you can switch back and forth between the two?
And I hope that the upcoming beta of the new code won't require a completely new database? So if you host a game on the regular site, players can access it from the beta site, and vice versa? And you can switch back and forth between the two?
[ Post comment ]