Is it good to use getters in a view?

I have two tables: Campaigns, Campaign_Stats. I need to display a list of campaigns with nested statistics.

To get started, I just had a method on the model that created an array like the following:

array(
    'id', // integer
    'campaign_name',// string
    'stats'// nested array of arrays with stats by periods
);

      

In the view, I had two foreach loops (one nested inside the other):

<? foreach ($this->campaigns as $campaign): ?>
    <div class="campaign">
        <?= $campaign['name'] ?>
        <? foreach($campaign['stats'] as $monthStats): ?>
            <div class="statistics">
                <?= $monthStats['views'] ?>
            </div>
        <? endforeach ?>
    </div>
<? endforeach ?>

      

This implementation of the model leads to confusing code, so I decided to try to make Campaign an object. In the view, I use getters:

<? foreach($this->campaigns as $campaign): ?>
    <div class="campaign">
    <?= $campaign->getName() ?>
    <? foreach($campaign->getMonthStats() as $monthStats): ?>
        <div class="statistics">
            <?= $monthStats->getViews() ?>
        </div>
    <? endforeach ?>
    </div>
<? endforeach ?>

      

I've never seen any framework use getters like this. What are the pros and cons of this approach?

+3


source to share


4 answers


The beauty with getters in object-oriented design is that they hide the complexity of computing the result. This way, you can change how the views are calculated and automatically updated in all applications.

Purists argue that you shouldn't have method calls on views, etc., but pragmatists like me are said to call method calls on views, since methods can be checked by a module. However, when you find that the outputs are getting too complex (Martin Fowler calls these objects too intimate with each other), you need to refactor to use a single method call.



Bottom line: Methods are good because their outputs can be tested

+4


source


I had the same arguments with my colleagues earlier and disagree with the use of methods inside a template. This makes the templates not transparent, there is no clear idea of ​​what is available inside the template - you should know the objects you are dealing with, and the designers, or developers who later join, should not worry about this, they should see what is happening with transmission in the controller that's all. Not to mention, method calls from within the template can modify data that has already been passed inside. And while I know that in some cases it's okay for the template to have changes in the loop or whatever, I tend to think the template is more static then the rest of the code - iterating over an array won't change any other array. But I'm not sure about objects.

It also adds an additional dependency for refactoring.



And it also adds complexity and seduction for developers to start calling SQL or doing heavy logic inside a template.

I could probably also point out that simple templating engines tend to be plain text substitutes. And methods are not an option for them.

+1


source


usually you won't see explicit getters, you will see people accessing properties.
However, this will only work if you are public.
Injecting Zend_Form into a view allows you to access elements and other attributes using getters and setters.
I see no major problem with the choice you have made.
However, I may have implemented a second foreach () using partialLoop () view helper, or perhaps create my own view helper, especially if this was something I intended to use in more than one place.

//example of what is commonly seen...
<? foreach($this->campaigns as $campaign): ?>
    <div class="campaign">
    <?= $campaign->name ?>
    <? foreach($campaign->stats as $monthStats): ?>
        <div class="statistics">
            <?= $monthStats->views() ?>
        </div>
    <? endforeach ?>
    </div>
<? endforeach ?>

      

Just my opinion, have fun.

+1


source


Sounds ok :) Magento allows for the same, for example.

Anyway, this is more a matter of personal opinion than anything ... But I tend to agree with you, it makes the model or controller easier to read (no need for $ view-> toto = $ model-> getToto ()

0


source







All Articles