Internet Bandaid   [RSS Feed]

Drupal is good…when you’re NOT using it

without comments

Hey guys, when it comes to module development, I think we’re going to stop relying on the drupal tools and instead develop with a traditional MVC approach within the drupal framework. For all future module development, things will be done in the following manner:

  1. Every feature will be comprised of two modules: i) module_name_model and ii) module_name_controller . All data request and data manipulation happens in the model module. All data transmission to templates happen in the controller module.
  2. All template files will exist in templates folder in the module_name_controller folder. In the future, templates might become a module on its such as module_name_templates.
  3. Controllers will access template files via php’s ob_start() and ob_get_clean() functions.

The objective of this set up is to improve the following:

  1. Make it easier to see what model functions exist and can be used by the entire project.
  2. Remove dependence on drupals theme() functions, and blocks etc… to reduce barrier to using drupal
  3. Too often, the a single modules does way too much

A few people asked, "Why not leave the model functions within the module?"

Answer: The reason is because we intend for the model functions to be re-useable model functions/objects that can be used by the rest of the project.

Although it wasn’t asked, but naturally, the follow up question should have been, "Let’s say you have a module called Financial System (that has controller and view files). According to your approach, that means you will need a module called Financial System Model. A possible issue with this is that the Financial System probably is not a single model or data object. Instead, it would be a large collection/library of other models. Imagine looking in /sites/all/modules directory and seeing a list of modules like: user_model module, user_role_model, photo_model, financial_system_model. In this list, the first three model are rather atomic (as in it’s very clear what business object in the real world it represents), but the last module…the financial_system_model…it is a behemoth module that groups many atomic models. This mires code homogeneity. Either have atomic model modules right in the modules folder, or have modules of libraries of models, but NOT both. When code is not homogenous/consistent, you’re encouraging software entropy."

My answer to that is – That’s COrrect. Let me back up, what i failed to mentioned originally was that I was speaking from the point of view of a person who is in the middle of re-factoring a very large project. Making ONE model module for every ONE controller module is only an intermediate step for re-factoring purposes. At the moment, we do not have a clear picture of how our model should be designed (which of course is not a good thing, and it stems from my limited understanding how best to use drupal in a git controlled dev environment as opposed to a db controlled dev environment). We can either have each model module be atomic (the first few items you mentioned), or each module be more like a library of models (the financial system model). We should eventually pick one approach or the other, but not both.

For now, we just want to separate the model from controller and view. Once we’ve done that, we can think about next steps.

Right now, the focus is to improve code readability. Any developer entering the system should not have to think twice where to write his/her new code.

Written by John Lai

January 12th, 2014 at 1:31 am

Posted in Uncategorized

Start Mission - Project management and invoicing

Leave a Reply