I think it would be useful to introduce a specialized View class so that this kind of logic, which relates only to one or two specific views can be encapsulated outside of the template itself. This makes it easier for designers to work with views, and for views to be localized. The base view class could also provide access to the current CHtml methods, which would make it easy to replace CHtml with your own class, solving a lot of the issues regarding supporting different CSS frameworks. Importantly, it also makes it much easier to test your views without relying on selenium.

Because that breaks the separation of concerns: models deal with manipulating data, views deal with displaying data, controllers just decide what model to display with which view. The controller shouldn't affect the presentation. Besides it's perfectly reasonable to use the same view with different controllers, so which controller should displayUserStatus() go in? The only real candidate is a helper class, but why not make that helper class part of the view?

I'm not saying we drop MVC at all, I'm saying that we should flesh out the V so that it's more in line with the original definition of MVC, with the view controlling the presentation rather than just being a template. This allows views to be extended and reused more easily, at the moment Yii is more like MTC - model template controller. Creating a custom view class would be totally optional, it would use the CView base class by default, which would leave things almost exactly the same as they are now, the only difference being that $this refers to the view, rather than the controller, and you no longer need static method calls to CHtml for generating text boxes and links etc.

No it does not totally fuck things up, its a very common use case, eg displaying a list of books for an author you might use views/book/_view.php in your list view, even though the current controller is AuthorController

Object views are not a good idea. Right now you have access to the controller right away and it has it's benefits (I have a use case when I have a custom controller level variable initialized in "init" witch the views needs - with view object I will have to pass it all over the place and that's not helping).
Over-engineering stuff is not healthy, widgets and clips are taking care of re-usability extremely well. I believe it should stay that way, the simplicity of the system is what makes Yii so good, it does not make you use object to simply render a view and that's great (and I have to remind about the beginContent/endContent and other functionality that controller has, some of it can just not work inside a view object. And it's damn useful - too good to be removed just to make a object view.

Right now you have access to the controller right away and it has it's benefits (I have a use case when I have a custom controller level variable initialized in "init" witch the views needs - with view object I will have to pass it all over the place and that's not helping).

You wouldn't have to pass anything round at all, instead of using:

$this->foo();

You'd just use

$this->controller->foo();

It's not so painful I think.

Psih, on 26 March 2012 - 09:16 AM, said:

it does not make you use object to simply render a view and that's great

I'm explicitly saying that you would never *have* to create a new View object, you could happily use the default view object and continue to put your logic in your controllers if that's what you want. So something like this

I have to remind about the beginContent/endContent and other functionality that controller has, some of it can just not work inside a view object. And it's damn useful - too good to be removed just to make a object view.

We wouldn't need to remove them. The point is you still have access to the controller if you need it via $this->controller.

I tend to agree to phpnode. While you can discuss a lot about how to implement such a view class in detail, to me it's quite clear that in the current implementation the controller deals way to much with the "V" part of MVC. We use objects for pretty much everything, but we suddenly leave this path when it comes to the View part. With a view class we could benefit from the usual OOP advantages. It would just be consequent to move all rendering logic and view related methods into the view domain.

But true, we already discussed this. Maybe we should revive the old thread instead.

I am a bit of a newbie when it comes to Yii and MVC but after reading everybodies thaughts on this I think we need to take a step back and define what we currently have and what want to get out of changing it.

Firstly, what is a View?
My understanding is that a view is for markup and layout and basic presentation stuff, not for logic.

The way I see it you looking for a preprocessing layer to a View where you can put logic, but then you have to ask yourself should this layer be able to alter variables/data being passed into the View from the Controller. And what about themes, are they also allowed to have logic or override the View logic?

I personally don't think another layer is necessary there are so many options already.