Audean Wiki

The goal here is to think what Drupy 3 should (or not) be. Previous versions were designed differently:

• Drupy 1 was designed out as a line-per-line PHP-to-Python port of the under-development Drupal 7
• Drupy 2 was designed as a rebuild of Drupal 7 main features on top of Django
• The goal for Drupy 3, besides improving my overall Python-fu, is to provide a Drupal-like developer experience (DX) and themer experience (TX) and admin experience (AX) on top of Python, without an additional framework layer

Drupy 1 shows how low-level porting to has been a trap, and actively discourages from pursuing in the same vein without higher-level thoughts.

• The hook mechanism. Refined from its inception to the generalizing categories of accumulators (hooks invokable via module_invoke_all) and alterators (hook_*_alter) while early/historical pseudo-hooks (hook_insert/update/delete…)
• The theme() mechanism, with its overlaid overrides, theme functions and templates
• Render arrays, with their properties (#) and elements (no #)
• Complete renouncement of basic PHP practice expected (forms, superglobals, sessions…)
• Refusal to give in to the MVC for the benefit of practitioners with more academic training than experience
• Storage
  • No ORM, but DB API virtualization
  • SQL mandatory (until D7), NoSQL available (D6 and later)
  • File management
• No mandatory content relationships
  • Taxonomy
  • 9-level deep book structure
• Content (until D6)
  • Everything rich is either a node, comment, or user account (until D6)
  • Every piece of rich content has a unique owner
  • Fieldable nodes (CCK) and accounts (Profile)
  • Terms and vocabularies are plain text
• Content (D7 and later)
  • Everything is a fieldable entity
  • Yes, even fields, although it may not be implemented yet
  • Including user accounts
• “Simpletest”
• IRC #drupal, #drupal-dev: possibly the single most important developer feature
• http://api.drupal.org: an always-up-to-date public API reference for anyone to use without having to set it up on their server

• Multiple themes
• Hierarchical templates
• RTL support
• Presupposed XHTML (until D7)

Something will have to give, here: Python seems to be unusable as a PHP-like templating language, thanks to its reliance on indentation.

• Online configuration, without a separate CLI installer/manager (à la Django or Rails)
  • Drush does not count, being contrib an addon
• Themable extensible query/report builder (Views)
• IRC #drupal-support: possibly the single most important developer feature