MVC and PHP

Today I read an absolutely horrible article in the CodeProject.  I don’t link to the article because, well, it’s really that bad, but the site itself seems pretty good.  Anyways, that all happened as I was reading more about what MVC technically is, as I’ve never had a use to look more into it in my programming.  Well, MVC stands for “Model, View, Controller”, meaning that each is kept separate from each other while programming.  Specifically, I looked in to Codeigniter, as that has been listed in a lot of web development job postings as a requirement to know.  While I read its documentation, I realized that it is essentially a collection of classes that preform various common actions that are used within PHP programming (The Controller aspect), with a few that would fit the View architecture of the design.

So, as this is basically How I have programmed in PHP since 2002, I decided to tab over to my Google search and clicked another link, one that took me to The MVC Paradox, by a published author on Software Development.  While reading his post, I felt like he missed the meaning of what ‘Views’ are in the design.  He said in his opening paragraph that Views are essentially supporting multiple clients, which he broke down with “Web Browsers” being first on the list.  Now, since I clicked all those Wikipedia links on the subject (and all the google ones that seamed reputable), and read quite about about what MVC really is suppose to mean, I found that most sources seem to agree that the view is what happens within the user’s web-browser.  He also said that Modern MVC Frameworks couple domain logic and user interface.  Since he didn’t define what domain logic was, I looked around and the most relevant definition I found was involving SQL statements, which is in the Model portion of the MVC. Now, I’ve known quite a few programmers, being as that’s what I studied in college; and absolutely none of them, or myself, couple the SQL statements directly to the output.  It always goes through some other process to modify it for output while in an OOP environment.  The blog continues to completely disregard every concept about MVC, calling all server-side classes ‘boilerplate code’ that bloat a project.

From what MVC frameworks that I found in PHP, most classes are separated quite nicely into modules that fit the design concept.  The code that I had used and reused in all my projects for display/SQL access/and authentication needs, included as classes as needed, with new code being written around it to complete those web-applications, fit the MVC design as well.  The blog author then links to and gives a code sample from the PHP 5 Micro Framework known as Slim, and Slim never claims to be MVC.  The blog author simply assumed that his own analysis of modern web systems was correct, and that all MVC Frameworks are simply “bloated boilerplate code”, and then passed us off to a small framework that does not follow the MVC design (read: it couples the model and view aspects into unintelligibly with its “Hello world” code.

So that author convoluted what MVC design is, and encourages you to use a RESTful approach instead.

In all of that, I learned one main thing, I never looked in to what MVC was because I had always insisted on recreating the wheel to begin with.  If I saw a class that did something useful, I’d program my own so as I know its exact features, and if it somehow managed not to be secure, I knew what I created and could troubleshoot it effectively.  Knowing that, I now get to start using CodeIgniter for my current project, just to check that box for the future.  I am glad that this project can take about 9-10 months, just to fully learn the framework as I make it (make it my own, in the way I learn their code).  At the same time, it’s a project I want to finish and have months to test before the intended opening next tournament season in 9 months.  So, here goes everything!

To Connect, or not to Connect.

To use FB Connect, or not to use FB Connect, that really is the question.

I spent hours looking for/creating a login page for Whostheblue.us, ended up finding a very nice login solution by RTD Front-end development that looks slick, and with some modifications I think would be perfect front page for the site.  However, after finding it, figuring out the code/css so that I could make modifications to it I realized that in today’s internet world, no one likes remembering passwords.  With the widespread use of Facebook Connect, allowing users to quickly and easily register and log on to sites, having Umpires that may or may not be”tech savvy” the ability to quickly register without having to remember new details may just be what my users will want. It would also allow events to be added to the umpire’s Facebook as well a few other “minor” features that would come with it.  However, if I ask myself what other advantages adding the social networking capabilities of Facebook Connect to the site would be – I find that there is no compelling reason to use it.  WhosTheBlue is a umpire scheduling system for organizations, all the data is contained, and privileges based upon the user’s role in the organization.  Adding a social network to that has no distinct advantages other than telling the umpire’s Facebook friends when and where they will be umpiring.

Umpire_Found

It took some time, but an umpire was finally found in a picture.

Umpiring is not a spectator sport.  Very few people go to baseball/softball games to watch the umpires, and one of the main goals of the umpire is to be invisible/transparent.  I would typically say that no one goes to watch them, but I do know some umpires that go just to see how other umpires work – though they typically go to professional (read: Major league/Minor league) games to see that.  So, the only reason to have events added to a user’s Facebook account would be for the sole purpose of telling others when they are not available.  Is that functionality worth the effort it would take to petition Facebook for an App ID, and all the extra programming it would take to save user’s 5 minutes of their time while registering?

As this site is for scheduling of games, requesting which games an umpire wants to do, etc – it would be required for the umpires of the organization using it to be a registered user regardless of how that registration takes place – adding it would be for the sole purpose of ease for the users, and being a subscription-based site, I am not sure I would be able to meet the Facebook Principles; as stated before, it wouldn’t inherently be a social experience.  So there is no real advantage for me, as a developer, to use the platform.

| Newer Entries »

    Search the Blog