"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.)