Model-Glue, Events... and Global Variables???

So there I was, sitting back and reading Doug Boude's recent post on The Model-Glue Event Lifecycle in Layman's Terms. Good article, I thought. Nice descriptions. Then one paragraph jumped out at me and I had a sudden realization: OMG, we've regressed back in time.

Here's the relevant portion of the paragraph: "The value “firstname” that we’re retrieving from ViewState is a value that was placed in the Event Bucket at some point previously in the event lifecycle, likely [sic] by one of our broadcasts. Are you seeing the beauty of the Event Object yet?"

And that's when it struck me. For all of our MVC object-oriented posturing, here all we've done is to go back in time. Back when the web didn't exist. Back when people programmed in arcane languages like BASIC and COBOL. And back when global variables ruled the land.

Because, when you get right down to it, that's exactly the pattern that's occurring in Doug's ViewState example. The view (a subroutine), depends on a global variable (firstname) that hopefully exists in the global space (ViewState). A variable that some other method (subroutine) promised to create and insert.

But remember why global variables were considered bad programming practice in the first place?

Side-effects.

There's no guarantee that firstname was actually created. No guarantee that the code won't change and that the message that creates firstname won't be removed. No guarantee that the message sequence will never be changed. And no guarantee that some other message that's creating a sidebar or some other page entity won't decide to create a firstname of its own, stomping all over the original value.

That's a lot of promises and guarantees.

Further, even if the global is created there's no guarantee that it's going to be the right type. At least with a method invocation (function call) you can tell the system to type-check passed parameters and return values.

I suppose you could add code to do the same in each message handler, checking for the existence of needed globals and type-checking for safety... but that seems like a lot of work. Especially for a system that's supposed to make our lives easier.

Funny, isn't it? We create "objects", give them fancy names like ViewState and collection, and all the while we're simply passing around a mishmash of global variables to a bunch of subroutines that we hope will be nice and play well together.

Odd, how the more things change...

Comments

[Joe Zack]

Very interesting perspective Mr. Internals.

[Doug Boude]

Michael...WHEW! When I read the first couple sentences of your post I thought "OH NO! I'VE UNDERSTOOD IT ALL WRONG AND MICHAEL'S GONNA CALL ME OUT!". Glad you liked my take on the MG event, though. :0)

I see exactly what it is you're saying. The huge looming question that your observations create, though, is: what is the better way? That's what I'm left wondering. MG and Mach II are my first forays into the OO world, so it's really all I know in an OO context...what are the alternatives to the event object?

[Michael Long]

Doug, there's a very, very long answer to that question (and probably the basis for several other posts), but here's the short one: We may have gone so far down the path in the quest for the holy grail of decoupling that we've thrown out the baby with the bathwater.

It's an important concept to be sure, but should it be the overriding mechanism that controls all of our development?

[Boyan]

I see your point on global vars in Model-Glue. However, I don't think this is a limitation to Model-Glue, ColdFusion or any other web languages. I believe it a limitation of the way the web was designed. In any programming language/framework that works on the web there are essentially 3 places to store/retrieve values - the url, the session and the application. While the url scope can be page/event specific, the session and application are pretty much global. No matter how object oriented your code is, the limitation is still there when you go to display the data on the web. What can you do?

[Sean Corfield]

I don't think there's any contradiction implicit in the event object nor do I believe it's a step back to the procedural world. The event object is created for each request and is passed into each listener and then "passed" into the views (remember that the views are actually included into a view context object that has viewState as a local variable - this is achieved through a custom tag invocation in the ViewRenderer).

In other words, it is a per-request data bus for communication between listeners and views.

Do you think static data members in C++ and Java are a step back too? You must think those are like global variables too?

The fact is that every OO language has some form of "global" variable that allows communication between different parts of the application.

The key difference between "globals" in procedural languages and static data in OO languages (or the event-based data bus in MG/M2 and FB5.1 and, no doubt, ColdBox), is that procedural globals occupy an unrestricted, flat namespace - whereas OO languages introduce boundaries and namespaces to improve modularity and reduce the potential for conflict.

[Michael Long]

Sean, I'll probably need to clarify this further in another post, but as I said you can call it a "per-request data bus for communication between listeners and views" if you want, but if you break it down that's still just a fancy way of saying it's a set of common variables that are global to all of those listeners and views for as long as that program (request) is running.

And, as I also pointed out, each listener or view is free to add, delete, or change any or all of the variables as it sees fit. Which can be both a blessing, and a curse.

True, every OO language has some form of "global" variable that allows communication between different parts of the application. But are global variables the preferred method of communication between every object and method in every OO language?

Didn't think so. But by effectively removing the "controller" from the MVC pattern, you're really left with no other choice.

[sohbet]

thanked post