[Routing] Check legacy code / maybe add BC (if necessary) / ...

[cmfcmf]

• Check what exactly happens in ModUtil::load() (as this is not used when an url is routed / the new abstract controller is used)
• Re-implement old Zikula Events (i.e. module_dispatch.preexecute) on calling Controllers when the Controller is called using a Symfony route.
  @Drak you said there are plenty of Symfony events now, but:
  • If these events are used by other modules, this is a BC break
  • Carefully check all core event listeners on these events (if any)

refs #1552.

[craigh]

ModUtil::load() does:

1. binds the domain: ZLanguage::bindModuleDomain($modname);
2. loads DB info self::dbInfoLoad($modname, $modinfo['directory']);
3. loads the module's stylesheet (and the admin stylesheet for admin controllers)
4. fires the event EventUtil::dispatch('module_dispatch.postloadgeneric', $event);

also "initializes" OO modules:
A. adds autoloader ZLoader::addAutoloader($moduleName, array(realpath("$modpath"), realpath("$modpath/$osdir/lib"),));
B. loads bootstrap.php file include_once $bootstrap;
C. attaches event handlers: EventUtil::attachCustomHandlers("config/EventHandlers/$osdir");
D. loads plugins PluginUtil::loadPlugins("$modpath/$osdir/plugins", "ModulePlugin_{$osdir}");
E. sets cache setting for isInitialized

[craigh]

1. is done in new AbstractController
2. is not required for modules using Doctrine
3. no sure about this, but move to Twig would impact it
4. I don't think something like this currently exists, but I think it could be done quite simply in AbstractController

A. I believe this is already taken care of
B. unsure
C. maybe moot as this method is deprecated and use of DIC is planned?
D. unsure
E. possibly unneeded?

[craigh]

ping @cmfcmf

[craigh]

I think letters B and D should take place in AbstractBundle::__construct()

number 3 might be taken care of in \Zikula\Core\Theme\Asset\CssResolver

[cmfcmf]

I think letters B and D should take place in AbstractBundle::__construct()

Seems reasonable.

[craigh]

The only thing I think that needs to be done on this ticket is to figure out how the module stylesheet will be automatically loaded. I think this can be therefore postponed until 1.5 because I don't think we can finalize that detail until Twig Themes are defined and this is planned for 1.5.

agreed?

[craigh]

one point - number 4 above - the event, IMO should be left out. It is not a BC concern because this is a new Controller and API so there is no need to maintain that event.

[cmfcmf]

Regarding the event: The Imagine SystemPlugin listens for it IIRC and so could other third party modules.

[craigh]

sure - and they would continue to work in old controllers. so that is not a BC problem. We could either provide a different event or force those listeners to listen to a core event or symfony event for the same purpose in the new controller. no?

[cmfcmf]

I'm wondering if the Imagine listener would still work: https://github.com/zikula/core/blob/1.4/src/plugins/Imagine/Plugin.php#L66-L97 (this one can be changed of course, but other third party modules can't be changed that easy)

[craigh]

of course. but even the line before that (https://github.com/zikula/core/blob/1.4/src/plugins/Imagine/Plugin.php#L65) will need to be changed probably when we move to twig (and the new controllers). My point is this: the old controllers will continue to work as is until v2.0.0. The new controllers will need to implement some other way to initialize things like the Imagine plugin (for that matter all plugins). And that will not be required until v2.0.0 but probably implemented in 1.5.0

[craigh]

I think this is really about deciding what the new controllers will implement with regard to 'old' (BC) stuff. Obviously, some functionality from the old methods will be copied directly (like possibly the firing of the event) or implemented in new ways that might also maintain BC. But we need to think carefully about what will and will not be in the new controllers even as we release 1.4 because that will become the new API that 2.0 will rest upon. We don't want to be haphazardly implementing stuff just to rip it out before 2.0.0.

[Guite]

👍 for keeping module_dispatch events even in 2.x since they implement what is described in http://symfony.com/doc/current/cookbook/event_dispatcher/before_after_filters.html

[craigh]

it would be nice if @Drak shared an opinion here.

[craigh]

👍 for keeping module_dispatch events even in 2.x since they implement what is described in http://symfony.com/doc/current/cookbook/event_dispatcher/before_after_filters.html

With respect, that page is making the case to eliminate firing our own event and relying on native symfony events. Which is sort of what I've been saying 😄

[craigh]

In this case, specifically the kernel.response event should work for this

[Guite]

Nice! Apparently I didn't remember the details correctly.

[craigh]

I'm closing this. I believe it is finished. The remaining issue about the event will need to be solved when Plugins are reconfigured.