Re: Why I dislike the MVC implementations in Web

It sounds like you're complaining about the way the different pieces are named. Who cares? You're right that the way Smalltalk defines things is not the same as most web versions do it, but that doesn't diminish the usefulness of the architecture. Jamming the logic for processing input and the logic for displaying it into one "component" doesn't seem like an improvement -- that will just make it hard to change the presentation when you need to.

To me, the bottom line is that a web architecture must support having a designer who doesn't know Perl working on the HTML. Template oriented structures like MVC do this well. Your architecture doesn't look like it will.

Comment on Re: Why I dislike the MVC implementations in Web

Replies are listed 'Best First'.

Re^2: Why I dislike the MVC implementations in Web
by ruoso (Curate) on Jun 07, 2005 at 21:09 UTC

Well, and that's why I said this only applies to complex information systems. This model fits very well for small applications that a designer will create the HTML for each page. For a bigger application, this starts to be a problem for maintainance of the software, and reduces the re-usability of the code.

BTW, the "component" model can be easy to designers, it's just a matter of creating a template file for each component, and allowing an entire form to be designed in a template, *BUT* instead of defining the HTML of each component, calling the desired component's render method, which would use a separated template and a separated render code, which would enable re-use and encapsulation of complex widgets (like the mentioned datetime field).

The first version of Oak doesn't use templates, really. But the model do allows me of using in the second version, which I will.

And... I'm not complaining about the naming, I just wanted to clarify that the Web implementations of MVC are not quite MVC, and that it would be nice if it was.

[reply]


Do you know where your variables are?
	PerlMonks