> Yes Fred, that'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>Well, my first question would be: what does this have to do with updating? If it's a simple db query, then it should have little/nothing to do with updating to a new version of Drupal. The only reason it should matter is if either the table names or fields changed (an easy fix) or you were actually using one of Drupal's APIs and that API changed (a harder fix). <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>Well, my opinion is that the best practice is to insist on this. If too many others agreed with you, you'd probably be building your own CMS right now...<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't like that, you shouldn't do it. <br><br>You are missing one giant caveat: the use of the term "when possible". We don't contribute everything back, but we do release *every single patch* we create. What would be the benefit of keeping it to ourselves? If we had a problem, someone else almost certainly did, and maintaining a forked version of any code (which is what a patched version of a module is) is expensive over time.<br>
<br>> Maybe Alex is right, but if so, that's news to me. <br><br>I think that would be news to many people. Hmm, I think I need to make that my twitter status! ;-)<br><br>--<br>Alex Urevick-Ackelsberg<br>ZivTech, LLC<br>
<a href="http://zivtech.com">http://zivtech.com</a><br><a href="mailto:alex@zivtech.com">alex@zivtech.com</a><br>office: (267) 940-7737<br>cell: (215) 866-8956<br>skype: zivtech<br>aim: zivtech<br><br><br>2009/3/29 Sam Cohen <<a href="mailto:sam@samcohen.com">sam@samcohen.com</a>><br>
>><br>>><br>>> I disagree. I think you didn'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>><br>><br>> Yes Fred, that'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's nothing "wrong" with building custom functionality that you don'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'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't like that, you shouldn't do it. <br>
><br>> Maybe Alex is right, but if so, that's news to me. It be great if some of the rest of you can chime in on this.<br>><br>> Sam<br>><br>><br>> _______________________________________________<br>
> consulting mailing list<br>> <a href="mailto:consulting@drupal.org">consulting@drupal.org</a><br>> <a href="http://lists.drupal.org/mailman/listinfo/consulting">http://lists.drupal.org/mailman/listinfo/consulting</a><br>
><br><br>