Although the refered piece makes sense I can think of some pro-MVC defences:
> You *never* have multiple > simultaneous controls or views to worry about I would not say never. Think about portal-like functionality. Sure in the end (the complete webpage) it is just one view, but is'nt that the same for most GUI apps (one total window)? Actually I'd like to look at my webapps as a composition of elements that have their own view and can all have different controllers. BTW.. this can be done by including commands like this: <c:import url="http://wholepathtoserver:port/cmd.m"/> it won't work with a relative path (like <c:import url="cmd.m") in Maverik (see one of my earlier posts). > 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. Depends on how you look at it... see above. > Flow of control is linear and predicatable. In the end it allways is, or is the author using random processing ;-) > 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). Mem model and single/ multiple user problems are IMHO not part of the problem that MVC solves. And the model is regenerated? What does it matter where I get the model from? > 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. Agreed. I see this a lot in web apps that use MVC frameworks. If you want to just display something of your model, just code it in your JSP, maybe using a null command (so that you can still do nice transforms). I think Maverik does a good job (better then some other frameworks) at providing a clean architecture to solve above problems. > 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 We work with design patterns to have a common basis of communication. Just consider talking about MVC in the context of web applications talking in a different accent. We globally mean the same as the traditional GUI guys, but have some small interpretation differences. I am pretty sure that most experienced programmers talking about MVC in a web context understand how the pattern works in their context. On the other hand... maybe we (programmers after the Smalltalk age?) are all just darn ignorant, and should lean from our coding ancestors ;-) (uh, sorry that was not very nice...) I think the author is right as well when he says that MVC does not solve all your problems (surprise, surprise). But it *does* give the community a nice proven method to make our webapps a bit less messy. Eelco Hillenius ----- Original Message ----- From: "Roman Petrov" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, February 11, 2003 11:26 AM Subject: [Mav-user] Interesting MVC post > What people think about this post? > http://lists.ourshack.com/pipermail/templates/2002-November/003974.html > > I think it's incorrect to say MVC for any web framework. > WebMVC? > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > [INVALID FOOTER] > > ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com [INVALID FOOTER]
