Yii Framework Forum: View and helper - Yii Framework Forum

Jump to content

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

View and helper

#21 User is offline   Ben 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 266
  • Joined: 15-March 09

Posted 22 July 2011 - 12:46 PM

Hm, I get results between -4% and 6%, although most runs end somewhere in between 2% and 4% (PHP 5.3.4 on WAMP 2.1).
Don't like ads in my sig...
0

#22 User is offline   Antonio Ramirez 

  • Elite Member
  • Yii
  • Group: Yii Dev Team
  • Posts: 1,448
  • Joined: 04-October 10

Posted 22 July 2011 - 12:55 PM

View Postmindplay, on 22 July 2011 - 09:33 AM, said:


My guess is, the introduction of namespaces in recent version of PHP has added some overhead to static method-calls...



Thanks for sharing mindplay. Done your benchmark in my computer and these are the results and is very clear:

1st
Static method-calls: 75.758 msec
Instance method-calls: 59.550 msec
Static method-call overhead: 27%

----
2nd
Static method-calls: 70.767 msec
Instance method-calls: 67.440 msec
Static method-call overhead: 5%

---
3rd
Static method-calls: 69.590 msec
Instance method-calls: 63.538 msec
Static method-call overhead: 10%


Benchmark running on MacOsx Lion, apache, PHP 5.3+
¿How long would it take for you to understand that you own nothing in this world?

www.ramirezcobos.com
www.2amigos.us
www.github.com/tonydspaniard
www.github.com/2amigos


Posted Image
0

#23 User is offline   mindplay 

  • Advanced Member
  • PipPipPip
  • Yii
  • Group: Members
  • Posts: 397
  • Joined: 03-September 09
  • Location:New York

Posted 22 July 2011 - 05:02 PM

View PostBen, on 22 July 2011 - 12:46 PM, said:

Hm, I get results between -4% and 6%, although most runs end somewhere in between 2% and 4% (PHP 5.3.4 on WAMP 2.1).


There are many variables, I'm sure - hardware, operating system and perhaps certain installed modules/extensions, such as a bytecode cache, could affect the results.

I would conclude that performance is probably comparable, or perhaps slightly better, for instance-methods on most systems.
0

#24 User is offline   phtamas 

  • Advanced Member
  • PipPipPip
  • Yii
  • Group: Members
  • Posts: 526
  • Joined: 26-February 11
  • Location:Mezőtúr, Hungary

Posted 24 July 2011 - 10:35 AM

View Postqiang, on 18 July 2011 - 02:59 PM, said:

Related with this we also have a design decision to make regarding "view". Currently, views in Yii are just PHP scripts. There's no view object (note that view renderer is a different thing). Questions are:

1. Should we create a view object in Yii 2.0?


I can see only one benefit of that: Controllers would become much easier to test if action methods returned a view object (instead of outputting anything directly). The actual rendering should be done somewhere in CWebApplication.
But if you just want to factor out template rendering from controllers - which is a good idea anyway - then a simple behavior that can be attached to controllers could do the job. Even the old familiar syntax ($this->render(), etc.) can be kept in this way.
0

#25 User is offline   mindplay 

  • Advanced Member
  • PipPipPip
  • Yii
  • Group: Members
  • Posts: 397
  • Joined: 03-September 09
  • Location:New York

Posted 31 July 2011 - 05:32 PM

View Postphtamas, on 24 July 2011 - 10:35 AM, said:

I can see only one benefit of that: Controllers would become much easier to test if action methods returned a view object (instead of outputting anything directly). The actual rendering should be done somewhere in CWebApplication.


That approach has both advantages and weak points.

Suppose for example you need to render more than one view for some reason - how would you return multiple view-objects, and how would you make sure they execute in order? Even if you could manage that, suppose the result of one view needs to be inserted into another, how would you achieve that?

The decision to let the framework take over a responsibility like this, always results in more complexity than you were probably expecting.

I think the approach more commonly taken by Yii, is to provide tools, but let you drive the tools - you push, Yii moves. Frameworks that pull rather than push end up having to make decisions, and you end up one step removed from the decision-making process. So you're trying to influence the decisions made by the framework, by providing a different response when it pulls, which is a much more difficult process to understand (and less transparent, and usually slower) than just pushing in the direction you want to go.

Explicitly rendering a view, the way Yii does now, does not prevent testing, by the way - two colleagues in my office recently created a "view renderer" which they plug in during unit testing, which passes the view-data back to the unit test before rendering the view.

Note that this is not necessarily an argument against having a view-object of some sort - there may well be other good reasons to abstract a view in the form of an object...
0

#26 User is offline   elbek 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 134
  • Joined: 22-July 10
  • Location:MA, USA

Posted 12 August 2011 - 11:33 AM

View Postqiang, on 18 July 2011 - 02:59 PM, said:

This is actually an old topic. We had some discussion before (http://code.google.c...s/detail?id=121), but still haven't reached a conclusion yet.

Basically, using static classes as helpers have two main drawbacks:

1. Because in Yii 2.0, we will use namespace, it will be troublesome to use static classes as helpers. For example, instead of writing 'CHtml::textField' in Yii 1.x, we will need to write 'yii\web\helpers\Html::textField' unless we use the namespace beforehand in the view script.
2. Static classes are difficult to be customized and extended.


Related with this we also have a design decision to make regarding "view". Currently, views in Yii are just PHP scripts. There's no view object (note that view renderer is a different thing). Questions are:

1. Should we create a view object in Yii 2.0?
2. If so, how can we maintain the current simplicity and efficiency in view usage?


It is good to be with helpers but of course as a statuc function in a Class not like CodeIgniter's helpers.
But i be not think we create view obj to render a view. If it will be created what will be benefits of it? Now there is a big benefit that in view file you can access to the controller (by $this) not like Zend framework's view file. Hovewer Zend framework crates a view object to show view file and it is a bit complicated. It is my opinion
Elbek
0

#27 User is offline   mindplay 

  • Advanced Member
  • PipPipPip
  • Yii
  • Group: Members
  • Posts: 397
  • Joined: 03-September 09
  • Location:New York

Posted 12 August 2011 - 08:40 PM

I like the approach used in ASP.NET MVC - every controller returns a "result", and there are different result-types, a view-result just happens to be one of them; other examples are JSON-result, file-result (for downloads) etc.
0

#28 User is offline   grigori 

  • Junior Member
  • Pip
  • Yii
  • Group: Members
  • Posts: 41
  • Joined: 06-February 11

Posted 15 August 2011 - 09:45 PM

View Postqiang, on 18 July 2011 - 02:59 PM, said:

1. it will be troublesome to use static classes as helpers

There are just a few helpers, it's easy to "use" them in a view renderer.

Quote

2. Static classes are difficult to be customized and extended.

This is the major drawback. Same as abnormal quantity of private variables all over the framework.
You can replace privates with protected and use static instead of self everywhere to assist in this task.

Quote

1. Should we create a view object in Yii 2.0?

Yes.
Controllers are really the view controllers, as we don't have event controllers in web, but the template engine should be separated from controllers.
Last project changed my mind - I think that a separate view is required.

Quote

2. If so, how can we maintain the current simplicity and efficiency in view usage?

What are the goals for changes in general? I did not find it in the texts.
0

#29 User is offline   kernel 

  • Junior Member
  • Pip
  • Yii
  • Group: Members
  • Posts: 91
  • Joined: 22-November 10

Posted 27 August 2011 - 07:23 AM

View Object could be a standaonle one, Not attaching to controller only. This object can be use in other place not limited in the controller this way: Yii::app()->controller->render() ... to Yii::app()->view ?
0

#30 User is offline   Rodrigo Coelho 

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

Posted 01 September 2011 - 08:02 PM

I like the way how Gustavo have outlined the helper magic methods.
But I'm against having the helpers (or its methods) in the view class as several people suggested. Helpers are also used outside the views.

Not using the helper class directly could bring a good side effect: more extensibility.
The developer will be able to just drop a new helper seamlessly. The helpers will have the same flexibility that components have today.
0

#31 User is offline   thyseus 

  • Advanced Member
  • PipPipPip
  • Yii
  • Group: Members
  • Posts: 300
  • Joined: 18-April 09
  • Location:Leipzig, Germany

Posted 03 September 2011 - 02:36 AM

I vote for a View object. Why?

1.) Doing translation without setting Yii::t() everywhere:

We could do something like this:

namespace Yii;
$obj = new View;
$obj->translationPath = 'app.messages'; // default
$obj->translationScope = 'application'; // default
$obj->language = 'de'; // default would be Yii::app()->language;

return $obj->retrieve('view'); // would return the output of view 'view';

$obj->render('view'); // would render view


Now, in the view file, wo would not use Yii:t() at all:

<p> Please translate me to german </p>


And, in the translation file app.messages.application.de we have a "intelligent"
string detector that translates all found strings in the view file:

'Please translate me to german' => 'Bitte übersetze mich in Deutsch'


Of course, other Message Source like CDbMessageSource, ... can be attached to the
view object, with the CPhpMessageSource as the default. The translated view then
will be cached - maybe even as a physical .php file with translated strings.

2.) Caching:

We could do something like this:

namespace Yii;

$dep = new CCacheDependency('select max(*) from users');
$obj = new View;
$obj->cache(500, $dep)->render('view');


to let yii automatically cache our view files

3.) Helpers and used templating language:

I do _not_ vote for a "default yii templating language". It
should stay the way it is, and templating languages should
be attachable. But a _minimal_ asset of shortcuts, without
injecting <?php ?> tags would really be helpful. Examples:

Instead of:

<row class="wide">
<?php echo CHtml::activeLabel($model, 'value'); ?>;
<?php echo CHtml::textArea($model, 'value'); ?>;
<?php echo CHtml::error($model, 'value'); ?>;
</row>


We could do (syntax needs to be discussed/voted for):

<% row model="model" value="value" divOptions="wide" type="textArea" %>


Same goes for links. How about

<% link route="//site/index" title="Click me" label="Home" %>


The view object would translate these snippets into the appropriate
<?php ?>, and of course caches these by default.

4.) Layout Handling:

namespace Yii;
$obj = new View;

$obj->layoutPath = 'views.layouts'; // default
$obj->layout = 'column2':

$obj->render('view'); // apply layout to view and render, like in Yii1

$obj->attachLayout = false;

$obj->render('view'); // do _not_ attach Layout, like renderPartial();



5.) rendering Text

instead of

$this->renderText($text);


we could do do a static function:

View::retrieveText($text);
View::renderText($text);


6.) Output processing (javascript)

namespace Yii;
$obj = new View;

$obj->outputProcessing = false; // default would be true
$obj->render('view'); // do not process output here




7.) Intelligent Ajax response

We could make the view object force to not apply the layout
when the request is a ajax request. Of course this can be
overridden by the developer if he wants it for whatever
reason?
2

#32 User is offline   dongbeta 

  • Junior Member
  • Pip
  • Yii
  • Group: Members
  • Posts: 58
  • Joined: 19-November 09

Posted 04 September 2011 - 01:34 AM

I agree with the "__callStatic" way
0

#33 User is offline   mindplay 

  • Advanced Member
  • PipPipPip
  • Yii
  • Group: Members
  • Posts: 397
  • Joined: 03-September 09
  • Location:New York

Posted 20 September 2011 - 08:38 PM

Here's a related thought that has occurred to me a lot lately.

Why don't views compile down to classes?

Before PHP had namespaces, the answer to this was simple: what are you going to name them? They would need to have some ugly machine-generated name, e.g. "views/users/profile.php" might compile into a class named "view_users_profile", which is yucky.

With namespaces available now, it would actually make more sense to compile views down to classes - so when you compile "MyApp/Views/Users/Profile.php", it actually compiles into a class with a (configurable) namespace, e.g. "MyApp\Views\Users\Profile".

This way, when you're looking at a module's folder structure, the folder-names really correspond to namespaces, and filenames really correspond to class-names.

The generated class can extend whatever view-engine it happens to be using, so you might end up with a compiled view like "MyApp\Views\Users\Profile extends \VendorABC\EngineX\View" which implements a render() method.

This opens up more new possibilities - for example, we can now allow multiple view engines in the same application, since view-engines only need to load/compile once, and whatever base-class they need will automatically be autoloaded as needed. After the first request, once the compiled templates are in place, you don't even need to run code that checks which view-engines are installed, they just autoload as needed.

Another thing that PHP developers are generally fearful of, is repeated rendering of the same view - with the traditional template engine approach (where a view compiles into a flat PHP script), rendering the same view 10 times is expensive, because you have to require/include the same flat script repeatedly.

If a view compiled into a class, you can load once and render repeatedly at no extra cost - because it's just a method-call on a class. Which is really all your HTML helpers are - they're mini templates that you can't practically implement as views, mainly because they would be too slow.

I benchmarked this a while back, and found that anything that renders more than once, renders faster when wrapped in a class and method-call, rather than multiple calls to include/require. Even with a bytecode cache.

I know this is a big detour from what you're used to, but give it some thought :-)
0

#34 User is offline   samdark 

  • Having fun
  • Yii
  • Group: Yii Dev Team
  • Posts: 3,338
  • Joined: 17-January 09
  • Location:Russia

Posted 21 September 2011 - 01:34 PM

Quote

This opens up more new possibilities - for example, we can now allow multiple view engines in the same application

It's supported in current Yii.


So your idea is to compile same flat files to classes and then running these?
Yii 1.1 Application Development Cookbook

Enjoying Yii? Star us at github: 1.1 and 2.0.
0

#35 User is offline   binkabir 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 193
  • Joined: 25-July 10
  • Location:Abuja,Nigeria

Posted 14 October 2011 - 03:12 AM

Hello, i think creating view object is a very good idea.
0

#36 User is offline   samdark 

  • Having fun
  • Yii
  • Group: Yii Dev Team
  • Posts: 3,338
  • Joined: 17-January 09
  • Location:Russia

Posted 14 October 2011 - 09:12 AM

binkabir
Why?
Yii 1.1 Application Development Cookbook

Enjoying Yii? Star us at github: 1.1 and 2.0.
0

#37 User is offline   binkabir 

  • Standard Member
  • PipPip
  • Yii
  • Group: Members
  • Posts: 193
  • Joined: 25-July 10
  • Location:Abuja,Nigeria

Posted 14 October 2011 - 11:03 AM

View Postsamdark, on 14 October 2011 - 09:12 AM, said:

binkabir
Why?

i think the view object should have all the helper methods (which will not be static functions)

example
  $output = new CView('path/to/view/file',array('myVar'=>$var)); 



because has all the helper method are in the CView object i should be able to do this
inside be view_file
$this->encode($myVar);

$this->ajax('ajaxName','url',array('options'));



one can also be able to do this
//this should encode all the data/variables passed to the view object
$output->encode();



this is my little concept ;)
0

#38 User is offline   jacmoe 

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

Posted 14 October 2011 - 01:12 PM

That's one of the bits I really didn't like about CakePHP - please don't duplicate that into Yii.
I really dig the simplicity of the fact that the controller is available in the view. :)

And why create yet another object?
"Less noise - more signal"
0

#39 User is offline   Antonio Ramirez 

  • Elite Member
  • Yii
  • Group: Yii Dev Team
  • Posts: 1,448
  • Joined: 04-October 10

Posted 14 October 2011 - 05:12 PM

The main doubt for me is, why would i have a view object?

Paths? I love the automated discovery on controllers, and the good thing is that if i need another one placed on different place i just pass the path and voilá...
Caching? are you sure the actual caching features do not accomplish nearly to perfection its mission?
Translation? i18n is perfect the way it is, can be improved of course, but automated tag discovery is error prone and will obviously reduce the speed of the library
Template commands? Wait a minute... templates inside HTML, just like other rendering engines out-there? I do not agree, if anybody wishes to use smarty or an engine, there are ways to do it. IMHO I opt to stick with pure HTML, is easier to work with designers. They can handle PHP tags, but template commands? forget it. Also, I think is a new step to interpret and reduce response time if not used well.

Those reasons above do not convince me to create a view object... there is one thing I have always problems with, and it is the way rendering takes place with javascript files, their order, the renderPartial process output approach that renders duplicated files again and again via AJAX, but is that part of the View object? I think not, is because our CClientScript component I believe.

So why do I need a view object? should we remove all the view rendering features from controller and create a separated object? maybe it is good for methods encapsulation, maybe in the future is better to improve it without affecting controllers code, but i do not find other good reason why do we need a view object.
¿How long would it take for you to understand that you own nothing in this world?

www.ramirezcobos.com
www.2amigos.us
www.github.com/tonydspaniard
www.github.com/2amigos


Posted Image
1

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