<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
<br>
</div>I disagree. I think you didn&#39;t understand Sam. I think he wrote a<br>
simple SQL call and a simple loop to display data, as opposed to<br>
writing a Views plugin module. For me at least that certainly would be<br>
FAR easier, then learning how to write a Views plugin.<br>
<font color="#888888"></font></blockquote><div><br><br>Yes Fred, that&#39;s exactly what I did.  It seems to me insist on a writing a plugin for so simple a task would have been overkill.  And if I had written a plugin, who bears the cost of my time maintaining that plugin -- the client?<br>
<br>But I think this is a really important conversation for Drupal customization.  <br><br>I have always thought that there&#39;s nothing &quot;wrong&quot; with building custom functionality that you don&#39;t contribute back --and the only time you would generalize it and contribute it back is if <br>
<br>1.  The client agrees and wants to pay for it<br>2.  You do it on your own time<br>3.  It&#39;s something that would be generally be useful to the community -- not too specific.<br><br>I always thought the best practice was to offer the client the option to generalize it and contribute it back, not that the best practice is to insist on it being done that way.  <br>
<br>It seems like Alex is arguing that the correct practice is that all customizations should be either contributed back as modules -- or I suppose -- contirbuted as patches and improvements on existing modules. And if a client doesn&#39;t like that, you shouldn&#39;t do it.  <br>
<br>Maybe Alex is right, but if so, that&#39;s news to me. It be great if some of the rest of you can chime in on this. <br><br>Sam<br></div></div><br>