Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-06-14T04:15:19.103Z
Answers.Text: 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?
Answers.UserDisplayName: kr37
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-06-14T14:42:13.230Z
Answers.Text: Correct. Of course, there are always exceptions, but the answer above is a good best practice guideline.
Answers.UserDisplayName: Aaron Berkowitz
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-06-13T18:09:22.517Z
Answers.LastActivityDate: 2015-06-13T18:09:22.517Z
Answers.UserDisplayName: Aaron Berkowitz
Body: <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>
  
Tags: <plugin-development><templating><variable>
Title: Can setRouteVariables be in Services?
ThreadText: # 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.  
  
  ---
  
  