Body: <p>For Market commerce, good example templates and snippets of code are very important.</p>
  
  <p>There is a few ways I can give these to the users of my plugin:</p>
  
  <p>1) Example template folder. The user would manually copy the folder of templates into their templates folder. This folder could include twig macros that they could import to use in their templates and also allows them to modify the snippets easily.</p>
  
  <p>2) Render a template partial from a Craft plugin Variable. This seems to be gaining a heap of popularity as I have looked through other plugins, but I don't really like the method as it does not allow users to update the code of the snippet without modifying templates in the plugins template directory. I also believe it is a remnant of eecms devs understanding of a antiquated templating system.</p>
  
  <p>3) Full blown twig extensions. This gives the flexibility of doing native tags for wrapping blocks of code, it also suffers from the same issue as number 2.</p>
  
  <p>I suppose a good solution would 1 &amp; 3. The ability to easy use macros I make, with the ability to edit, but also an easy way to get core snippets of template functionality without needing to touch the html.</p>
  
  <p>Maybe this is too open a question for SE, but what do you suggest is the best way to solve these issues. Should people stop putting html snippets into PluginVariables.php?</p>
  
  <p><strong>I suggest to P&amp;T</strong> to enable a "pluginName/macros" folder to give designers the ability to import macros from the front end that they need without having to copy a whole folder of example code? This would allow the plugin dev to update the supplied macros at any time, but the designer can pick and choose which ones they want to copy into their templates folder and customize.</p>
  
  <p>Suggestions and Ideas?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-23T18:50:10.527Z
Comments.Text: Sounds like this is half question/half feature request. Probably worth posting here as well: http://feedback.buildwithcraft.com/forums/285221-feature-requests
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-24T05:56:29.310Z
Comments.Text: Yeah thought so @BradBell but doubt it's gonna get 100 votes since its developer focused. Might look to manually enable macros available in the front end.
Comments.UserDisplayName: Luke Holder
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-24T12:06:38.290Z
Comments.Text: I struggle to see benefits for the user in editing macros in pluginName/macros over editing template code in pluginName/templates. In my opinion you shouldn't make your plugin users touch your plugin's folder at all.
Comments.UserDisplayName: carlcs
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-24T12:19:17.197Z
Comments.Text: But let's discuss this over at feedback.buildwithcraft.com, there's a reason P&T allows comments there. And I actually don't think it's all about the votes, they know for sure that API or localisation related feature requests are less popular but important nevertheless.
Comments.UserDisplayName: carlcs
Tags: <plugin-development><templating><macro>
Title: Macros vs Variables, which one should I choose to give users of my plugin?
ThreadText: # Macros vs Variables, which one should I choose to give users of my plugin?
  
  (Asked by: username_0 on 2015-03-23)
  
  For Market commerce, good example templates and snippets of code are very important.
  
  There is a few ways I can give these to the users of my plugin:
  
  1) Example template folder. The user would manually copy the folder of templates into their templates folder. This folder could include twig macros that they could import to use in their templates and also allows them to modify the snippets easily.
  
  2) Render a template partial from a Craft plugin Variable. This seems to be gaining a heap of popularity as I have looked through other plugins, but I don't really like the method as it does not allow users to update the code of the snippet without modifying templates in the plugins template directory. I also believe it is a remnant of eecms devs understanding of a antiquated templating system.
  
  3) Full blown twig extensions. This gives the flexibility of doing native tags for wrapping blocks of code, it also suffers from the same issue as number 2.
  
  I suppose a good solution would 1 & 3. The ability to easy use macros I make, with the ability to edit, but also an easy way to get core snippets of template functionality without needing to touch the html.
  
  Maybe this is too open a question for SE, but what do you suggest is the best way to solve these issues. Should people stop putting html snippets into PluginVariables.php?
  
  **I suggest to P&T** to enable a "pluginName/macros" folder to give designers the ability to import macros from the front end that they need without having to copy a whole folder of example code? This would allow the plugin dev to update the supplied macros at any time, but the designer can pick and choose which ones they want to copy into their templates folder and customize.
  
  Suggestions and Ideas?
  
  **Tags:** plugin-development, templating, macro
  
  > **Comments:**
  > **username_1**: Sounds like this is half question/half feature request. Probably worth posting here as well: http://feedback.buildwithcraft.com/forums/285221-feature-requests  
  > **username_0**: Yeah thought so @username_1 but doubt it's gonna get 100 votes since its developer focused. Might look to manually enable macros available in the front end.  
  > **username_2**: I struggle to see benefits for the user in editing macros in pluginName/macros over editing template code in pluginName/templates. In my opinion you shouldn't make your plugin users touch your plugin's folder at all.  
  > **username_2**: But let's discuss this over at feedback.buildwithcraft.com, there's a reason P&T allows comments there. And I actually don't think it's all about the votes, they know for sure that API or localisation related feature requests are less popular but important nevertheless.  
  
  ---
  
  ## 0 answers
  
  