Your SlideShare is downloading. ×
Write Less Drupal Code
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Write Less Drupal Code

844
views

Published on

Better support for external libraries.

Better support for external libraries.

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
844
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Much of the code we are maintaining in Drupal today isn’t actually Drupal specific.
  • 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.
  • 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.
  • 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().
  • 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.
  • 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.
  • Transcript

    • 1. Let’s write less Drupal code. Alex Barth (alex_b)
    • 2. Much of the code 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 these don’t seem to be a big deal: check_plain()
    • 5. Others do: openid.inc (609 lines)
    • 6. PubsubHubbub
    • 7. If I had had 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 RDF parser 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 to share 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