Sea Bass wrote: > I've heard people say that the ability to access objects directly breaks "MVC" > separation. I'm not sure what MVC they are talking about, because in > Smalltalk's MVC allowing "View" code to query "Model" objects is a necessary > part of the pattern.
Indeed. I have come to the conclusion that most people who talk about MVC in regard to web application design don't properly understand what it is, how it should be used, what it's good for and more importantly, what it's not good for. Traditional MVC is ideally suited to time invariant applications (like your typical windowing application). Your application might have 3 dozen different buttons, sliders, entry fields, window controls, and so on. Any of these "controls" can be pressed at any one particular time, should signal the application "model" to do the Right Thing, and then cause one or more display "views" to be updated to reflect the new state of the model. MVC is designed to solve the problem of *simultaneously* having multiple control entry points, and multiple display outputs, and it acheives that very elegantly. But web applications only ever have one entry point and one output point - the request and the response. You *never* have multiple simultaneous controls or views to worry about, so there's little point applying traditional MVC to solve this non-existant problem. Your application, be it a CGI script, mod_perl handler, or even an all-in-one embedded Perl template, receives one and only one request for any one invocation, and it must generate one and only one response. Flow of control is linear and predicatable. Desktop MVC applications are typically single-user and the in-memory model persists for a session (e.g. while the application is running). In contrast, web applications are multi-user, and in most cases, the per-user model is regenerated on each request (i.e. by restoring a user's session data from a database on each request). There are other differences: controllers are inputs, not chunks of application code as they are portrayed in many web application frameworks; presentation elements can safely contain "programming" code, as long as it's presentation programming, not application programming; the model is the application state, not the application architecture, and so on. What the MVC-for-the-web crowd are really trying to achieve is a clear separation of concerns. Put your database code in one place, your application code in another, your presentation code in a third place. That way, you can chop and change different elements at will, hopefully without affecting the other parts (depending on how well your concerns are separated, of course). This is common sense and good practice. MVC achieves this separation of concerns as a by-product of clearly separating inputs (controls) and outputs (views). So IMHO, it's separation of concerns they should worry about, not MVC. The two are different things, albeit working in a similar manner. MVC is (mostly) designed to solve problems that web applications don't have. It is by no means the be-all and end-all of design patterns for web programming. Far from it. In fact, there are plenty of other design patterns that are equally, or more relevant to web applications and to writing good, solid code that clearly separates concerns. For example, the Chain of Responsibility (to implement a pipeline processing model), Mediator/Facade (to abstract internals behind clean interfaces to ease SOC), Strategy (to define a general strategy for all web applications that can be specialised for different requests), Abstract Factory and Factory Methods (to allow different implementations to be switched in/out) and so on. Alas, it seems that many web developers (and template module authors), miss these because they've been told that MVC is all they ever need. > 2) TT syntax is orthagonal to HTML/XML. I like having template code stand out > from my HTML/XML code. After all, their purposes are very different. Absolutely. Separation of concerns. Keep similar things similar, and different things different. A _______________________________________________ templates mailing list [EMAIL PROTECTED] http://lists.ourshack.com/mailman/listinfo/templates
