[development] Build or Buy?

[Gary (Lists)]

"Khalid B" wrote:

>> Anyway, there are some __very under-represented__ tools called 'pat', or PHP
>> Application Tools.  They are open-source and they are brilliant.
>> 
>> <http://www.php-tools.net/site.php>
>> 
>> Drupal should really consider using parts of this system. It provides all
>> kinds of rock-solid code, professional development of code, and a
>> lightning-fast PHP templating system, complete with cacheable templates.
>> 
>> I think others might want to check these tools out.  They are not "beginner"
>> really, but they are still not hard to use.  (I would say Beginner Plus is
>> about all that's needed...and some idea of PHP classes and objects.)
>> 
>> I still rely on 'pat' to do very much of the work at a number of sites, and
>> I will continue to use 'pat' even with Drupal.  I've been using 'pat' for
>> about 2 years now, and I find a number of the modules to be stunning in
>> their quality and clarity.
>> 
>> patForms, patNewsletter, patRSS, patTemplate, and more.
> 
> Hi Gary
> 
> I would like to comment on your post above in another topic.
> 
> This is the usual "build" or "buy" debate.

Well put phrase.

> Years ago when I started with Drupal, I was wondering like you why we do not
> use other tools that exist out there. I saw a lot of the resistance to
> integrate stuff from other projects as the NIH mentality (Not Invented Here),
> and reinventing the wheel.
> 
> Over time, I started to see that what makes Drupal unique is that we put in it
> stuff that we a) build to fit the need, and b) control ourselves.
> 
> One bad case where we relied on a third part component (xmlrpc library), that
> was unmaintained, caused us severe headaches with security at one point. We
> rewrote it from scratch to get over this.

Yes, I've encountered this problem with AppleScript applications which used
similarly abandoned external tools.  It's a problem.  (But, it's a potential
problem with any OSS out there, really.  One day it might just stop.)

("You can't stop my drop!"  Not Drupal, of course ;)

> Another point is the javascript stuff in core. There are libraries out there
> (Scriptalicious/Prototype), but they are BIG. Steven Wittens wrote a set of
> minimal AJAX javascript libraries that is today in core. Jeff Robins took the
> S/P libraries and wrote a contributed module around it.

I hear you, man.  I love -- and stick exclusively to -- the 'JS 1k API',
which is a great little chunk of code that will fit neatly into...well, 1k.

> As long as the license is GPL, feel free to write a contributed module around
> anything that already exists out there. It is all about choice: those who want
> lean will stick with core, those who do not mind the bloat and want the
> functionality will pick the contrib part.

I hear you, again, brother.  (And 'pat' is, so that's cool.)

> If something really stands out in contrib, it becomes a candidate for core
> with a little "marketing" and persuasion, but it has to be really outstanding
> to be included.
> 
> Just my $0.02

Well spent.  And worth far more.


Thanks for the skinny, the scoop, the low-down.
--
Gary

Whose job today is to complete the one-week old 'Drupal Module Plug-ins'
system we've been playing with. I really want many more modules to have an
attached plug-ins folder, to change their flavor.

We spent three days last week rolling our own Drupal Plug-ins system
experiment, which was a blast (and we learned a great deal about Drupal.)

Now, we can do things like change the look-up URL for our Geo-IP mods to the
watchdog module.  Rather than write a bloated function, we just scan a
plug-ins folder (at the same directory level as 'modules') and this works
for two modules so far.

Just like 'themes' might have flavors, so, too, can certain modules.  Weird,
but working (mostly.)