CiviCRM Community Forums (archive)

+1 on include_path -- would prefer a standard autoloading mechanism supported by extensions. composer-based extension management is one solution (with pros/cons -- more standard/popular and includes dependency management, but mostly used for CLI, and mostly engineered for managing code instead of DBs).

I've done some experiments with exposing Doctrine entities with RESTful interface, e.g.

https://github.com/totten/civicrm-core/blob/doctrine-hateoas/Civi/Core/Worldregion.php#L47

It works with Doctrine entities, but we haven't examined how to define Doctrine entities in extensions. (The class-loader is likely to be one part; the DB upgrades is likely to be another part.)

FWIW, this ( https://github.com/totten/civicrm-core/commit/80e6dbd4e196c0959cbe4c9f99edc99359805ea7 ) uses a technique that I think is neat -- ie scanning (for classes with annotations) and storing an index (in a cache). It's a compelling pattern for handling resource registrations.

--

Regarding hooks and Event Dispatcher, I have somewhat mixed feelings. Event Dispatcher is more flexible, and I suspect it's slightly more recognizable for WP/Joomla developers, and I'd personally choose it when writing a new application. But Drupal developers are a big constituency for Civi, and Drupal-style hooks probably have the broadest recognition in our community. It doesn't need to be either/or (one can simultaneously support both hook- and EventDispatcher-interfaces for the same events), but I have mixed feelings about supporting multiple-ways-to-do-the-same-thing. If we supported ED, wouldn't we want to deprecate hooks?

I like having some 'conventions' so you know where to find stuff.

Not only is this an important factor in orienting new developers, but also facilitates collaboration as when looking at a piece of code you did not write you are in 'known territory' and can immediately understand how it works (well, most of the time anyway!).

That said, the include_path is a PITA and most certainly leads to reduced performance.

So maybe a middle-ground solution would be that the extension manager does 'scan' the extension code via a standard pattern and creates the registrations automatically (ie. scan the <ext-root>/api for any files, use the file name to create a registration, no need to add to include_path anymore). This might be done during the extension installation process and cached somewhere.

This might be a big plus as well in terms of security: when installing a new extension, we could have a page that lists all it implements based on this scan/cache - ie. defines new apis (with the list of), replaces core files, changes database schema, adds menu items, etc.

Just brainstorming and it's getting late ...