« The good, the bad, and the different - iPhone edition | Main | Mobile Web Design »

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

The comments to this entry are closed.