Breakdowns «
»


Games: , , ,
2 comments

When Jim asked me how many hours I could put to So Play We All this week, I said “Negative three”. That turned out to be pretty accurate, as I managed to drop on the floor all but the three most important things for my week. Unfortunately, Oaqn didn’t make that top three so I sent $20 each to Jim and Luke. So, let’s look at what I funded this week.

Luke had writer’s block, so there’s not a lot to say there. I’m a bit puzzled that he doesn’t say “coder’s blocK” because the hours are budgeted towards that, but I can see how it’d be easy to open a code editor and then stare at it.

I’ve chatted with Luke a bit about his game design and thought it was pretty solid, similar to stuff I’d seen on Three Hundred Mechanics . This really sounds like he’s trying to see the entire design up-front and getting overwhelmed by it. His big questions are all certainly important ones, but maybe it’s worth figuring out if there’s a way to take smaller bites.

Jim’s got his first progress that doesn’t sound to me like he’s reinventing a wheel. The template for a page is broken down into DisplayRegions, each of which has a Controller (“Component”) responsible for loading the right data.

It’s an interesting PHP-styled take on MVC. The top-level code that handles each request isn’t a controller action, it’s basically a template split into code/settings (“DisplayEngine”) and markup (“PageTemplate”). The template then lists what controllers and actions should be invoked to handle the request, which is a not how I’ve ever seen any web MVC work before. It feels pretty stereotypical of PHP to have a template running the show, and I wonder how much logic is going to leak into them as a result. A common pattern is that a section of a page with links to register and sign in — or, if there’s a user logged-in, to edit account settings and log out. Jim, in your system, where does that if (logged_in()) { [settings/logout template] } else { [register/login template] } live?


Comments

  1. That decision gets made by the User View rendering the User object. For example, a single User might be rendered multiple times on a single page. Once in the header indicating the login/logout template you describe. Maybe each time a post is listed by author, maybe another segment in the sidebar listing the 5 most active users, etc., etc.. In each case, the User object simply exists. It is the responsibility of a View to translate the model’s data into something meaningful to the end user based upon the context in which it appears.

    And, yes, that was my original point with making my own framework. There’s not many truly MVC frameworks built using PHP because the approach they all try and take is to use index.php as the one and only controller.

    Unfortunately, some things are so general that is is reinventing the wheel… But you need to do them anyways unless you’re using an existing system. However, from this point on is where my framework should start to diverge from the norm. Hopefully with the flexibility that I have planned for it. :)

Leave a Reply

Your email address will not be published.