The same question for Tags:

// Register Observer for Tags.
JObserverMapper::addObserverClassToClass('JTableObserverTags', 'VideosTableVideo', array('typeAlias' => 'com_videos.video'));

Hi @brunobatista

Indeed, we need to provide guidelines for extensions.

Right now, if you have a system plugin you can add it to the system plugin, that way the Observer is registered for all requests. Or if you need to observe those classes while executing your component only, just add it to the constructor of your controller. But never in the Observer nor in the Observable classes: The goal of that pattern is that the 2 classes should not know each other and not depend on each other. In other terms, to not rely to each other. E.g. one of the uses could be to replace core JTags by an extension's Tags class without changing anything in the core. Or, as you seen use it for the History for anything !

When I designed and introduced the Observers to Joomla to solve the hard-coded dependancy of JTable to JTags, and avoid even more hardcodings, it was to propose a cleaner fix a bug as first priority, but also at the same time to fix it cleanly by introducing this major missing Design Pattern. By lack of time, and need to further explore the best way for extensions and core, the best already available place, where already other CMS-related bindings were made was cms.php, in the wait of a better place to be created for them :-) .

I will propose a new Observers Definitions pattern for cleanly declaring Observers outside the observed and observer classes for extensions and core uses, to remove the need of a system plugin for the extension. But I want that to also solve a few more problems and add a higher-level architecture mapping pattern. Sounds pretty abstract and complex, but it's actually not a huge amount of lines of code, and it could save thousands of lines. Just I need a bit more time to proposa a software-architecture solution.

One possibility could be to declare them formally in the extension manifest file and then store them into an ObserverMappersCollections, possibly stored in the database (e.g. in the #__extensions table) and automatically mapped by the CMS when starting without further need of system plugin or other declarations. Those architecture thoughts go into the direction of more formal architecture descriptions-driven efficient execution instead of implementation-driven injections. But it needs a bit more dedicated time to think it fully through, before proposing it. And for now, we have 3.2 to finish working on ;-)

So easiest for you is either in the Controller constructor, or if also needed outside your component in a system plugin that you can add to the package of your extension to install and uninstall automatically.

Hope that helps :-)

Awesome! Thanks a lot to help me!