NaX - it’s perfectly legitimate to put logic in the view, as long as that logic relates to the presentation. But if you need to reuse that logic, you can’t easily at the moment.
NaX - it’s perfectly legitimate to put logic in the view, as long as that logic relates to the presentation. But if you need to reuse that logic, you can’t easily at the moment.
Maybe I’m just liking the current state too much, but let me say that people ruined too much good things with good intentions not realizing where to stop.
Please remember the KISS principle. I see that a View Object has it’s potential, but is it really worth adding more objects. Is there a real need for that? My concern is doing OOP for the sake of OOP (yea, maybe adding some functionality, but nothing really major) just to add some rare case functionality? Why? It can’t be done in other way? Is it the only way to solve your problem? How many other people really need it?
It’s really not a rare case, I’d say 70% of the views in the apps I work on have presentation logic that would be better placed elsewhere. It is impossible for designers without Yii skills to work with views in the current system. Also, using locale specific views instead of Yii::t() is a real pain, because if you change your presentation logic, you need to update a load of different files. It is one more class, the overhead is basically nothing because existing presentation related code would just be moved to the view class, but there are a load of very real advantages. I don’t really see the disadvantages tbh.
I’d say “humor me” with a good example of what you mean. I have multi-language applications and I never had issues with current system that would screw-up my attempts of building apps with different languages (except I would like to have ability to actually use native gettext extension and not the substitute)
I don’t think it is a bad idea to have a view class and a template to handle the presentation, leaving the controller to handle the request (and some of the response) specifics.
I understand phpnode’s pain with multilanguage views.
Also, it is a pain when the designer is PHP-blind.
Having a view class and a template, the template will have only [font=“Courier New”]echo[/font], [font=“Courier New”]if[/font] and [font=“Courier New”]foreach[/font]. The template can be designer’s property and very little code is to be understood as very little code will be there.
The view object would assign even the widget markup to the variable that would be used in an [font="Courier New"]echo[/font] in the view.
Besides this, if i were to pass a anonymous function for styling to my model (which would be the correct way to do it), i often end up not doing it because i do not want functions in my views.
A solution this would be nice (not worth coding for yourself though if you dont need them that much).
Perhaps it is time to talk about how views, controllers and renderers work together atm. This is fine as long as some HTML is generated. But already Yii’s ajax validation requires to break the processing chain by explicitly calling Yii::app()->end(). Same if I generate (or deliver) binary files: Whenever I do that, I need to escape the processing chain. From an engineering perspective, that’s not exactly nice.
Another thing is the renderer: There’s one for the entire application. Yes, I can replace it. But two renderers can never co-exist, I actually need to replace one. At least temporarily. No matter how I do that, it always feels a bit like cheating the system. I think it would help a lot already, if there were a real CHttpResponse class that could be returned by a controller’s action as well as a CController.renderer property, so one could set the renderer per-controller (in addition to system-wide).
So, that’s pretty ot for the moment. This is actualy an excerpt from a longer text that I screpped for the sake of brevity (it also sounded unnecessarily harsh at times). Considering a CView class: After some additional thought, it might make sense to have one if one and the same content is to be delivered in different forms. E.g. as HTML, JSON and RDF. When I worked on the concept for XUL support for Yii, this would have helped immensily.
Here’s an implementation of CHttpResponse that didn’t get accepted into 1.1 because it’s too much of a change, you should be able to use it in your application though
Nice implementation. I especially like the use of X-Sendfile. However, I wonder why you haven’t decided to split your response class into subclasses such as a CXmlHttpResponse or CJsonHttpResponse.
@Da:Sourcerer That’s a very good point actually. A lot of sites provide APIs offering XML or JSON support in addition to their HTML representation, that’s a fact. It would be nice to have greater flexibility in choosing the presentation of your data. Putting all the logic into the controller or adding api modules with basically the same logic but different presentation forms feels wrong. A CView might be the better way to achieve that
Because when you’re first creating a response, you might not know (or care) what kind of response it is until it’s being rendered. If we have multiple response classes, you have to know in advance what type of response you want to show. Perhaps this could be worked around though.
Maybe by a generic response class? 
Hm, I’ve got two proposals for your response class:
[list=1]
[*] Handle header names lowercase (at least internally). This would eliminate one possible error source early (Content-type vs. cOnten-tYpe etc.)
[*] There are more headers that can be folded than Cache-Control. Vary is a notable one. Perhaps you should handle them differently?
[/list]
Feel free to make those changes, I was planning to release this as an extension after it didn’t get accepted into the core but I’ve not got round to it yet
A bit invasive for an extension, isn’t it? However, I think it’s very much worth working on it. Could be very well resulting into a prototype for Yii 2 
Not if you just have the CHttpResponse class and lose the changes to CController etc.
Wow - how opinionated I sound in my fight against a separate view object… 
However, now - after realizing that it would be a good idea to use a view object with a template engine like Mustache - I’ve changed my mind completely.
Just sayin’
I see that a view object made it’s way into Yii2, so I’ll dig up the latest relevant topic…