To answer your questions:

“How can your web designer modify the table appearance (for example, adding a caption)”

Easily since table appearance is controlled in the CSS and since the table tag itself is not generated in the PHP.

“You should read (or re-read) the PoEAA book : logic is allowed in the views, but PRESENTATION logic, and not BUSINESS logic”

I am not a dogmatic nerd, my opinion is based on my experience. My experience has shown if you logic in the views (business or presentation) web designers can easily bust it.

Conclusion - you are an angry nerd:
http://www.killerphp.com/articles/angry-self-righteous-tech-nerds/

2. You should read (or re-read) the PoEAA book : logic is allowed in the views, but PRESENTATION logic, and not BUSINESS logic

Conclusion : you wrote another useless post, which will help to confuse even more people who still doesn’t get MVC. For them, thank you…

That is the whole point of the view, to allow the designer to take it and run with it by adding class names, ids, whatever, then be able to test that without having to publish it to a web server. This is very important: some designers will not be publishing to a testing server every 30 seconds to test a design. If they’re working in Dreamweaver or some other WYSIWYG app, a designer will get a rough idea of how the design is working. When I set up a view to use this loop:

this works in Dreamweaver. Yes, the actual data is not there yet, but the designer can see how the CSS is behaving (roughly) without having to publish to a server. Also, I’m using the template-style PHP syntax since that is more easily understood by the designer.

Better yet, using the standard Code Igniter parsing system, you can do this:

{things}

{things_t}

{/things}

Code Igniter takes care of the data structure, and the designer can see the {things_t} in the design to get an idea of where the final data will go. And this templating style is pretty easy for a designer to figure out what’s going on and what he should change and not change.

Long story short, give the designer everything he might ever need to update the design so you don’t get a call a year from now when they want to do a refresh. Your job is to make your data structure work, not tell the designer what to do.

I may get to it at some point but for now, I have a lot on my plate.

From what I’ve seen, the cleanest separation of responsibility (and the most flexible implementation) is a Strong Model, which has been brilliantly characterized by Bill Karwin, in a discussion thread on his own blog last week: “Ideally, the Controller should serve as a thin layer to pass application inputs to the Model classes, and then pass the Models to the Views.” This puts the smarts of the app into the Models, which are hopefully designed to be able to export that updated data into formats that can either be prepared for databases/repositories or formats that can be parsed easily by Views and ViewHelpers.

A Strong Model IS your application. It just executes instructions that have been parsed by the Controller/Request and it can relay its data (upon request) in formats both the database and the Views can use. To answer your issue, a View/ViewHelper should be smart and capable enough to render either string data or to parse arrays as necessary, but under no circumstances should either a Controller or a Model render HTML. The fun part is that there is no rule which says a Strong Model can’t know how to use a Weak Model for database interactions.

In an ideal world, of course.

–

It’s annoying to me to have to write a ‘page-widget’ object for every little building block of the layout and the associated html. If it’s just one quick if() to swich 1 sentence and loop out 4 anchors in the footer based on if you’re logged in or not, I don’t think that justifies a whole new widget object.

–

@Keith Jackson - Display ALWAYS needs loops. I have not had a single project where there wasn’t lots of looping all over the place. News categories, photo gallery images, paginated search results, related documents, select lists, all need looping through an array or result set.

–

We recently reviewed a couple of our sites and generated some html widget objects from the most common elements. The very next site we did, while using the same features that used those widgets, needed to look so completely different that the widgets were of no use to us. But since the controller was already giving the needed data to the widget I decided to make the widged return both the original data and it’s version of the html out put so that if need be we can simply loop through the original data in the view to do what we need instead of just echoing the widget’s default markup.

–

Also, totally agree with Rick.

Don’t get me wrong, it’s perfectly feasible for a designer to learn to program views. But the key is *views require programming, by a programmer*. In many cases the view logic can be by far the most esoteric and complex of an application (note, logic, not necessarily code itself, depending on the abstractions used).

A view is the underlying manifestation of a design, not the design itself - just as a well defined model is the manifestation of the real life objects it represents.

As explained in a previous comment, the MVC paradigm was designed to separate the logic of an application in to well defined categories. Show me one accepted definition of MVC where it states that code should not be used in a view. You wont find one.
Without such code, a view just becomes a static page and we may as well be using plain html - unless the code is moved somewhere else; this “somewhere else” however absolutely MUST still be in the view domain, otherwise you lose all the benefits of the MVC paradigm. In fact you’d likely be better off going back to the old page controller setup of yesteryear.

When it comes down to it, an ideal development team will have the expertise of a model programmer, a controller programmer, a view programmer and a designer. It may well be the case that one person can take on more than one of those roles, even all of them, however the skills must be aquired in each role to do so. The ideas brought forward by this blog post represent the wrong solution to the wrong problem.

PS. Apologies for the rant-esque nature of my post.. This is in no way derogatory towards anyone in particular. I just find this whole topic rather frustrating!