Download to read offline
Uploaded byAlex Barth
Write Less Drupal Code
The document discusses how much of the code being maintained for Drupal is not actually Drupal-specific and proposes solutions to write less Drupal code by leveraging external libraries. It provides examples of non-Drupal specific functions and files that take up significant lines of code. The author suggests allowing modules to share external libraries, moving non-Drupal code out of the core, and using a tool to package modules with external libraries.
Write Less Drupal Code
- 1. Let’s write lessDrupal code. Alex Barth (alex_b)
- 2. Much of thecode we are maintaining isn’t actually Drupal-specific.
- 3. jquery.js aggregator.parser.inc valid_url()filter_xss() check_plain() drupal_parse_info_format() jquery.once.js drupal_http_request() drupal_depth_first_search() password.inc
- 4. Some of thesedon’t seem to be a big deal: check_plain()
- 5. Others do: openid.inc(609 lines)
- 6.
- 7. If I hadhad check_plain() drupal_http_request() valid_url() my code would be shorter now and I could have written it in less time.
- 8. RSS/Atom parser RDFparser OAuth Activity Streams Saman Pub/sub Ever more jQuery for UI Some existing challenges that will benefit form good external library support:
- 9. Allow modules toshare external libraries by adding them to the search path: sites/all/libraries (Libraries module) Move non-Drupal-specific code into a separate include file(s) - make them externally available? Use drush_make to package modules with external libraries. (Some) solutions
Editor's Notes
- #3 Much of the code we are maintaining in Drupal today isn’t actually Drupal specific.
- #4 All these are functions or libraries that are either external libraries or that could very easily be part of an external library. None of them is Drupal-specific.
- #6 Recently we found a series of problems with Drupal’s OpenID implementation. We should share our implementation with other projects to minimize these sorts of glitches.
- #7 It would be not just beneficial to use more of other project’s code but to also make Drupal’s code available to other projects where it makes sense. Consider this example. I have written a PubsubHubbub subscriber and hub in a non-Drupal specific manner. In a nascent technology like PubsubHubbub it is crucial to share on the lowest common denominator: in this case, PHP. It was actually easy to write the library Drupal independent, but it was also a pain not to be able to rely on Drupal’s convenient library: drupal_http_request(), valid_url(), check_plain().
- #8 I couldn’t use any of the useful Drupal helper functions like check_plain() although they’re is no reason why they would be Drupal specific.
- #9 The application layer on the web is getting shaped by more and more standards and common best practices. We can’t afford to have a Drupal-only implementation for all of them. We need to get better in integrating with non-Drupal specific code. Let’s open the doors.