<p>Services are not meant for rendering templates, but for business logic, saving data, and retrieving data. The <code>setRouteVariables</code> method should only be used in a controller to send some information to a variable.</p>

<p>You can use a controller to reach out to a service for some data, then use the controller to report that data back to the view for display using the <code>setRouteVariables</code> function. You can skirt around this by using <a href="http://buildwithcraft.com/docs/plugins/variables" rel="nofollow">Variables</a> to directly call services, using a separate variable for each service function.</p>

<blockquote>
  <p>On a related note, is it possible for twig to instantiate a plugin's
  model, with access to all it's properties?</p>
</blockquote>

<p>Not directly, and this shouldn't be done. It is best practice to not have views directly instantiating models, but to have controllers and services act as the middle-men. It will help keep your code testable, reusable, and readable. </p>

<p>From the Craft documentation: </p>

<p><a href="http://buildwithcraft.com/docs/plugins/controllers" rel="nofollow">Controllers</a></p>

<blockquote>
  <p>Generally speaking, controllers are the middlemen between the front
  end of the CP/website and your plugin’s services. They contain action
  methods which handle individual tasks.</p>
</blockquote>

<p><a href="http://buildwithcraft.com/docs/plugins/services" rel="nofollow">Services</a></p>

<blockquote>
  <p>All of your plugin’s business logic should go in services, including
  saving data, retrieving data, etc. They provide APIs that your
  controllers, template variables, and other plugins can interact with.</p>
</blockquote>

CC BY-SA 3.0
2015-06-14T04:15:19.103Z
Thank you, this is helpful.  To clarify then, for a calendar plugin, the routines to produce a full calendar or a mini calendar should be happening in an action method in a controller, rather than in services?
kr37
CC BY-SA 3.0
2015-06-14T14:42:13.230Z
Correct. Of course, there are always exceptions, but the answer above is a good best practice guideline.
Aaron Berkowitz
CC BY-SA 3.0
2015-06-13T18:09:22.517Z
2015-06-13T18:09:22.517Z
Aaron Berkowitz
<p>It seems that something like</p>

<pre><code>craft()-&gt;urlManager-&gt;setRouteVariables(array('calupdateResponse' =&gt; $out));
</code></pre>

<p>works in a Controller so that {{ calupdateResponse }} has a value, but it doesn't work in a function in a plugin's Services (no error, just no values show up in twig).</p>

<p>I'm wishing that a single function in Services can output a number of variables to twig for templating. What is the most straightforward way?   Is it necessary to create a function for each one in PluginVariables.php?  Then I have many functions instead of just one.  This is for a CP page, if that makes a difference.</p>

<p>On a related note, is it possible for twig to instantiate a plugin's model, with access to all it's properties?</p>

<p>Thank you!</p>

<plugin-development><templating><variable>
Can setRouteVariables be in Services?
# Can setRouteVariables be in Services?

(Asked by: username_0 on 2015-06-12)

It seems that something like
craft()->urlManager->setRouteVariables(array('calupdateResponse' => $out));

works in a Controller so that {{ calupdateResponse }} has a value, but it doesn't work in a function in a plugin's Services (no error, just no values show up in twig).
I'm wishing that a single function in Services can output a number of variables to twig for templating. What is the most straightforward way?   Is it necessary to create a function for each one in PluginVariables.php?  Then I have many functions instead of just one.  This is for a CP page, if that makes a difference.
On a related note, is it possible for twig to instantiate a plugin's model, with access to all it's properties?
Thank you!

**Tags:** plugin-development, templating, variable

---

## 1 answers

### Answer by username_1 on 2015-06-13. Score: 4 | Accepted answer

Services are not meant for rendering templates, but for business logic, saving data, and retrieving data. The `setRouteVariables` method should only be used in a controller to send some information to a variable.

You can use a controller to reach out to a service for some data, then use the controller to report that data back to the view for display using the `setRouteVariables` function. You can skirt around this by using [Variables](http://buildwithcraft.com/docs/plugins/variables) to directly call services, using a separate variable for each service function.

> On a related note, is it possible for twig to instantiate a plugin's
> model, with access to all it's properties?

Not directly, and this shouldn't be done. It is best practice to not have views directly instantiating models, but to have controllers and services act as the middle-men. It will help keep your code testable, reusable, and readable.

From the Craft documentation:

[Controllers](http://buildwithcraft.com/docs/plugins/controllers)

> Generally speaking, controllers are the middlemen between the front
> end of the CP/website and your plugin’s services. They contain action
> methods which handle individual tasks.

[Services](http://buildwithcraft.com/docs/plugins/services)

> All of your plugin’s business logic should go in services, including
> saving data, retrieving data, etc. They provide APIs that your
> controllers, template variables, and other plugins can interact with.

> **Comments:**
> **username_0**: Thank you, this is helpful.  To clarify then, for a calendar plugin, the routines to produce a full calendar or a mini calendar should be happening in an action method in a controller, rather than in services?  
> **username_1**: Correct. Of course, there are always exceptions, but the answer above is a good best practice guideline.  

---

