Latest sites

Quick news

  • 2014-03-27: MongoDB Watchdog module ported to Drupal 8 at the Szeged Dev Days.
  • 2014-01-26: My post on the Symfony web profiler in Silex selected in Week of Symfony. w00t !
  • 2013-10-18: My first commit went into MongoDB today. And, guess what ? It's in JavaScript
  • 2013-09-20 to 29: Working on Drupal 8 EntityAPI at the extended code sprints during and around DrupalCon Prague
  • 2012-08-19: Working on Drupal 8 EntityAPI at Drupalcon Munich
  • 2012-06-15: Working on Drupal 8 EntityAPI at DrupalDevDays Barcelona
  • 2012-03-23: Working on the future Drupal Document Oriented Storage at DrupalCon Denver. D8 or later ? Bets are on Later

Grokking Drupal: module dependencies in e-Commerce 4

Roughly two years ago, I prepared a diagram of the dependencies in the then-current version of Drupal e-Commerce (eC) for Drupal 4.6.

Dependency diagram for Drupal e-Commerce 4 Now, with other eC projects looming ahead, a possible session about eC at Szeged, and eC 4 being in alpha, I figured it was time to update the model. Boy, has it changed ! Click the thumbnail for the full-size view.

Since this is not an UML diagram, some explanations are in order:

  • the purplish boxes are individual eC modules
  • the striped blue boxes are non-eC modules needed by eC modules
  • dependencies arrows point to the module from which a module depends. That is, for instance, "store" depends on "EC mail"
  • the dashed dependency from "ec Region" to external module "Location" is there because "eC Region" does not actually depend on "Location", but has added features if "Location" is present.
  • the yellow boxes are eC "packages", which you'll see at admin/build/modules
  • every eC module not in one of these packages is in the eC miscellaneous package
  • letters in a round box are dependency factorings, to reduce clutter. Thus, "Address" in the "eC Customer Interface" package depends on "Customer" through the "C" dependency factoring

As you'll notice by examining the diagram in detail, some of the dependencies are redundant. For instance, "Invoice" is marked as depending on both "Store" and "eC Checkout", but the latter already depends on "Store", so the direct dependency could be dropped since it does not introduce new information. In this diagram, they are taken from the .info files, and could be reduced to a minimal chain. Remember, eC 4 is still in alpha, so improvements are likely to come.

Easter Egg in July: I've left out one (minor) dependency. Will you find it ?

Any win?

Is there any win by removing the redundant dependencies? If so, where does the win occur? I would think it would in the module listings since it doesn't have to check for each dependency, but I wonder how much is actually saved.

Readability

Performance-wise, I'd hazard there's no significant gain to be expected: this is only code, no DB involved, only used on admin pages, and D5, for which eC4 is being built, does not perform dynamic loading based on the .info. This is only a readability/maintenability note.