Differences

This shows you the differences between two versions of the page.

--- dr:what [2010/09/05 15:34] – created fgm
+++ dr:what [2020/11/23 17:23] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
-Of course, Drupal has historically been about the community more than the software, but this is not the point. The question here is: what defines the Drupal experience technically, be it for developers, themers, or content authors
+====== What defines Drupal ? ======
+Of course, Drupal has historically been about the community more than the software, but this is not the point. The question here is: what defines the Drupal experience technically, be it for developers, themers, or content authors.
+==== Why ? ====
+The goal here is to think what [[dr/drupyx|Drupyx]] should (or not) be. Similar previous attempts were designed differently:
+  * Drupy 1 was designed as a line-per-line [[http://php2python.org|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 Drupyx, besides improving the overall Python-fu at OSInet, is to provide a Drupal-like developer experience (DX), themer experience (TX), and admin experience (AX) on top of Python, without an additional framework layer
+Drupy 1 shows how low-level porting has been a trap, and actively discourages from pursuing in the same vein without higher-level thoughts.
+Discussion transferred to http://groups.drupal.org/node/108604
+==== Developers ====
   * 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 items (no #)
+  * Render arrays, with their properties (#) and elements (no #)
-  * Online configuration, without a separate CLI installer/manager application (à la Django or Rails)
+  * Complete renouncement of basic PHP practice expected (forms, superglobals, sessions...)
-  * Refusal to give in to the MVC for the benefits of theorists
+  * 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
+==== Themers ====
+  * Multiple themes
+  * Hierarchical templates
+  * RTL support
+  * Presupposed XHTML (until D7)
+  * Blue :-)
+Something will have to give, here: Python seems to be unusable as a PHP-like templating language, thanks to its reliance on indentation.
+==== Admins ====
+  * 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