Yii Framework Forum: Views as objects - Yii Framework Forum

Jump to content

  • (2 Pages)
  • +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

Views as objects

#21 User is offline   phpnode 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 141
  • Joined: 18-April 11

Posted 26 March 2012 - 04:28 PM

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.
0

#22 User is offline   Psih 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 114
  • Joined: 30-June 10

Posted 27 March 2012 - 06:15 AM

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?
1

#23 User is offline   phpnode 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 141
  • Joined: 18-April 11

Posted 27 March 2012 - 06:32 AM

View PostPsih, on 27 March 2012 - 06:15 AM, said:

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.
2

#24 User is offline   Psih 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 114
  • Joined: 30-June 10

Posted 27 March 2012 - 06:40 AM

View Postphpnode, on 27 March 2012 - 06:32 AM, said:

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)
0

#25 User is offline   Rodrigo Coelho 

  • Master Member
  • PipPipPipPip
  • Yii
  • Group: Members
  • Posts: 665
  • Joined: 05-August 10
  • Location:Rio de Janeiro, Brazil

Posted 27 March 2012 - 08:52 AM

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 echo, if and foreach. 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 echo in the view.
0

#26 User is offline   JulianRutten 

  • Newbie
  • Yii
  • Group: Members
  • Posts: 9
  • Joined: 08-September 11
  • Location:Noord-Brabant, The Netherlands

Posted 28 March 2012 - 09:27 AM

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).
0

#27 User is offline   Da:Sourcerer 

  • Elite Member
  • PipPipPipPipPip
  • Yii
  • Group: Members
  • Posts: 1,222
  • Joined: 30-March 11
  • Location:Berlin, Germany

Posted 31 March 2012 - 11:07 AM

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.
programmer /ˈprəʊgramə/, noun: a device that converts ►coffee into ►code
0

#28 User is offline   phpnode 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 141
  • Joined: 18-April 11

Posted 31 March 2012 - 02:37 PM

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

https://github.com/y.../pull/346/files
0

#29 User is offline   Da:Sourcerer 

  • Elite Member
  • PipPipPipPipPip
  • Yii
  • Group: Members
  • Posts: 1,222
  • Joined: 30-March 11
  • Location:Berlin, Germany

Posted 02 April 2012 - 11:04 AM

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.
programmer /ˈprəʊgramə/, noun: a device that converts ►coffee into ►code
0

#30 User is offline   Haensel 

  • Advanced Member
  • PipPipPip
  • Yii
  • Group: Members
  • Posts: 444
  • Joined: 14-January 11
  • Location:Vienna (Austria)

Posted 04 April 2012 - 03:49 AM

@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
2

#31 User is offline   phpnode 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 141
  • Joined: 18-April 11

Posted 04 April 2012 - 04:50 AM

View PostDa:Sourcerer, on 02 April 2012 - 11:04 AM, said:

I wonder why you haven't decided to split your response class into subclasses such as a CXmlHttpResponse or CJsonHttpResponse.


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.
0

#32 User is offline   Da:Sourcerer 

  • Elite Member
  • PipPipPipPipPip
  • Yii
  • Group: Members
  • Posts: 1,222
  • Joined: 30-March 11
  • Location:Berlin, Germany

Posted 04 April 2012 - 05:05 AM

View Postphpnode, on 04 April 2012 - 04:50 AM, said:

Perhaps this could be worked around though.

Maybe by a generic response class? ;)
programmer /ˈprəʊgramə/, noun: a device that converts ►coffee into ►code
0

#33 User is offline   Da:Sourcerer 

  • Elite Member
  • PipPipPipPipPip
  • Yii
  • Group: Members
  • Posts: 1,222
  • Joined: 30-March 11
  • Location:Berlin, Germany

Posted 05 April 2012 - 07:34 AM

Hm, I've got two proposals for your response class:
  • 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?

programmer /ˈprəʊgramə/, noun: a device that converts ►coffee into ►code
0

#34 User is offline   phpnode 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 141
  • Joined: 18-April 11

Posted 05 April 2012 - 01:04 PM

View PostDa:Sourcerer, on 05 April 2012 - 07:34 AM, said:

Hm, I've got two proposals for your response class:
  • 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?




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
0

#35 User is offline   Da:Sourcerer 

  • Elite Member
  • PipPipPipPipPip
  • Yii
  • Group: Members
  • Posts: 1,222
  • Joined: 30-March 11
  • Location:Berlin, Germany

Posted 06 April 2012 - 07:39 AM

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 :lol:
programmer /ˈprəʊgramə/, noun: a device that converts ►coffee into ►code
0

#36 User is offline   phpnode 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 141
  • Joined: 18-April 11

Posted 06 April 2012 - 08:33 AM

View PostDa:Sourcerer, on 06 April 2012 - 07:39 AM, said:

A bit invasive for an extension, isn't it?


Not if you just have the CHttpResponse class and lose the changes to CController etc.
0

#37 User is offline   jacmoe 

  • Elite Member
  • Yii
  • Group: Moderators
  • Posts: 2,601
  • Joined: 10-October 10
  • Location:Denmark

Posted 08 May 2013 - 06:26 PM

Wow - how opinionated I sound in my fight against a separate view object.. :blink:

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' :lol:

I see that a view object made it's way into Yii2, so I'll dig up the latest relevant topic..
"Less noise - more signal"
0

Share this topic:


  • (2 Pages)
  • +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users