[development] Custom Theme Settings, Duplication, and Sandboxes

Victor Kane victorkane at gmail.com
Sun May 13 11:49:53 UTC 2007

Guys (this is to all of you), you are all doing good work.
A little less guilt-tripped bowing down to some god of open source will go a
long way here.
Don't let anyone guilt-trip you into stuff.
I am relatively new to the Drupal community (only a year and a half) but I
think the Drupal way is marked by three words: cooperation, selflessness and
above all intelligence.
Cooperation: If you see someone carrying a load, help her.
Selflessness: Take due credit for stuff, but don't do stuff to get credit.
Intelligence: The beauty of Drupal is, speaking broadly, separation of
model/view/controller and software reuse.

On that last point, what you can see is people coming into Drupal thinking
that "module" is a block of functionality appearing somewhere on a page.
Here, in Drupal-land, a "module" is a group of files mainly concerned with
controller logic and the resources necessary for the implementation of this
logic, totally separated from general theming, and relying on a database
abstraction layer for its persistence. So people generally try to use the
accepted standards in accessing the database, and try to use the theming
function conventions so that any theming decisions can be overridden.

That keeps things clean.

And, people try to reuse modules, and that keeps things clean.

If, in your Sandbox, you want to play around with some functionality, no-one
should stop you, just go ahead and have a ball. Of course, before starting,
it is simply good, intelligent software practice to attempt to reuse an
existing module rather than inventing the wheel.

This is not only to keep things clean. This is to keep things strong by
reusing proven code rather than slapping non-proven code into our machines.

Then, when it comes time to say, hey this deserves to be a module, common
sense would say look around and see what module integration is possible (two
examples here are jstools and swftools, among many); talk to people who are
doing similar stuff; if you think it is original and useful, publish your

Then, let people vote with their feet: if two or three similar modules are
out there, people will vote with their feet, which is much more effective
than having some incipient bureaucracy deem what is fit. Then, usually when
a new release comes out the unwanted and unloved modules usually don't get
updated, and nature has its course.

Case in point: Salesforce module.
1. My client needs salesforce integration urgently for a current project.
2. I prefer to see that done in the form of re-use of a module rather than
hacking stuff together individually, so that my client can benefit from
community code while the community benefits from my client's project. My
client understands this and applauds it.
3. I find a perfectly neat salesforce module in a fellow drupaler sandbox; I
see his wishlist saying "gosh darn it, wish I could find someone to take
this pesky salesforce module off my hands". I pm him, saying "I'm your man".
4. With Steve McKenzie's permission, I take his sandbox module and import it
as a bonafide module.
5. I am now testing it, have corrected some things and will publish shortly
4.7.x and a 5.x releases.
6. I will then extend the module with the additional functionality my client
needs (views support for online queries, to name one). Exciting!
7. Then, I get mail and messages saying: hey, what about unifying this with
access and integration modules with other CRM's, including CivicCRM, etc.
and I answer, cool, let me get this on the road, then let's discuss how that
can be done. The more discussion we have on that the better.
8. It's the year 2008. My client decides to switch to CivicCRM or its
on-demand (proprietary) version instead of the bad proprietary Salesforce.
It is a totally painless operation since all that needs to be done is switch
a configuration setting and do some import/export (a feature of the module
itself hahaha). So, any Salesforce diehards can stay with the bad
proprietary Salesforce, whilst do-gooders can go with the good proprietary
CivicCRM on-demand version. Sweet!

Drupal does it again!


Victor Kane

On 5/13/07, FGM <fgm at osinet.fr> wrote:
> Hi all in this thread,
> Just to clarify some points, which I think may be needed to spare some
> anguish, seeing how the thread appears unduly long:
> - When I saw this announcement, I was indeed surprised to see the
> duplication, and checked the three issues mentioned by John but, alas, I
> overlooked part of 54990 and thought he had not taken into account my
> remark
> on that issue, that pointed to the module in my sandbox. My fault.
> - I certainly do not attempt to deny anyone the idea of creating such a
> project. Indeed on the page where I announce the themesettings module I
> had
> in my sandbox, I explain rather clearly that it is just a
> "proof-of-concept"
> module, until something appears in core (which I hoped for 5.0, seeing how
> garland had its own settings mechanism, although done differently). So,
> since this
> - As John said, "we are all writing Open Source software", so I answered
> to
> the announcement to point to potential duplication, as Earl Miles
> initially
> remarked, not for a rights issue, as some others seem to have thought.
> However, John apparently was aware of this existing module, and indeed
> uses
> the same mechanism, in a much more developed code, in his function
> themesettingsapi_form_alter, so apparently there is no duplication, just a
> (very significant) functionality and packaging extension.
> - In the end, I think I was a bit miffed to discover a module by the same
> name as mine in the dev list, after the fact without any personal mail
> from
> the author especially since we had indeed exchanged some emails five weeks
> ago. So I think that to avoid similar problems for future occurences like
> this, John's latest suggestion in this thread makes sense:
> "Code duplication:
> Perhaps it needs to be a requirement that module developer's announce
> their
> project on this list BEFORE any code becomes public on the d.o website.
> [...] perhaps just documenting it in the appropriate places in the
> handbook
> would be enough."
> As far as I'm concerned, that's all there is to it, and I'm now pointing
> users of this sandbox module to his project (I know some exist, because I
> had received mails about it), because this being a project, it is supposed
> to be maintained and evolve, unlike a sandbox, which in this case
> fulfilled
> what IMHO seems to be its role: show ideas until they become ready for
> prime
> time. I'd actually have done it earlier if the module had been
> preannounced.
> Frederic
> ----- Original Message -----
> From: "John" <drupal.user at albin.net>
> To: <development at drupal.org>
> Sent: Friday, May 11, 2007 10:16 AM
> Subject: Re: [development] Custom Theme Settings
> > On May 11, 2007, at 12:27 AM, FGM wrote:
> > > Funny how you created a "themesettings" module that duplicates my own
> > > "themesettings" module..
> > >
> > > Is it the same mechanism/code ?
> >
> > Federick, head on over to the Theme Settings project and take a look
> > at the themesettingsapi.module code yourself: http://drupal.org/
> > project/themesettings
> >
> > Also, look at the project home page under "About the Project" and
> > you'll see I referenced issue #54990 where you announced your sandbox
> > module.  It's not the same code, but even if it was... aren't we all
> > writing Open Source software?  :-)
> >
> >   - John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070513/ae3cf5d5/attachment.htm 

More information about the development mailing list