Perrin Harkins wrote: > That definitely is what I've always meant by MVC.
When I said "Most people don't seem to understand MVC..." I should have added "...present company excepted, of course" :-) > I could say something like "command classes + data objects + > templates", but it doesn't have the same ring or historical proof behind it. Sure, I realise that most people use the term to mean something slightly different to what Smalltalkers or the Gang of Four would call MVC. I guess I even use it myself in that context. What annoys me is when I hear that TT can't be used to build MVC systems because it allows objects in the code, subroutine callbacks, embedded Perl code (which is disabled by default) and so on. This is pure nonsense written by people who clearly don't understand MVC, TT, or both. I've seen at least one cleanly written and well abstracted system written in Embperl (yep, pure embedded Perl) and some hideously crufty crap written using HTML::Template. But some people (present company excepted, of course :-) would have you believe that HTML::Template is the only template module worth using because it's the only one that supports MVC. These people are not worth saving... It's too late for them :-) (I should point out that World Domination is not my thing - I'm quite happy that HTML::Template rocks at whatever it does, and I'm well aware that TT sucks at certain things - it's the misinformation and miseducation that I'm trying to address) > Of course some people use MVC to abstract different types of inputs as > well (web browser vs. cell phone vs. cron job), but that's not common. As I was writing my tirade, I did wonder if you could build a pure MVC system, treating each incoming URL like a controller and each side-effect (including data impressions, page generation, etc.) as a view. But I haven't quite managed to get my head around that crazy idea yet... > Is there a better way to describe this sort of thing without the baggage > of arguing about what a controller is, etc.? I suppose that in the end, a name is just a name. It's fine to call it MVC, ABC or XYZ, or whatever best gets across the message. But I think we should also preach caution against taking the word of MVC too literally. It's better to teach people how to build well abstracted systems, than give then a set of strict rules to follow that may not be all that relevant. Objects, callbacks, and embedded Perl do not, by themselves, break MVC or create a poor separation of concerns. Hmmm, there might be a TPC paper in this... A _______________________________________________ templates mailing list [EMAIL PROTECTED] http://lists.ourshack.com/mailman/listinfo/templates
