[dev.icinga.com #13064] Replace TableLoader and FormLoader with a generic ClassLoader

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/13064

Created by mfrosch on 2016-11-08 07:47:28 +00:00

Assignee: mfrosch
Status: New
Target Version: (none)
Last Update: 2016-11-08 09:56:07 +00:00 (in Redmine)

---

Currently, Tables can not extend other tables, because of a non existing auto-loader.

Idea is to replace the existing FormLoader and TableLoader with an additional spl_autoload ClassLoader.

The Form contexts gets auto-loaded by icingaweb2, Tables not yet.

Changesets

2016-11-08 07:59:54 +00:00 by mfrosch 9169da0

ClassLoader: Introduce additional ClassLoader

The Loader replaces TableLoader in a generic manner. FormLoader is handled by Icinga\Application\ClassLoader for every module.

refs #13064

2016-11-28 17:12:49 +00:00 by mfrosch 038d777

ClassLoader: Introduce additional ClassLoader

The Loader replaces TableLoader in a generic manner. FormLoader is handled by Icinga\Application\ClassLoader for every module.

refs #13064

[icinga-migration]

Updated by tgelf on 2016-11-08 08:48:52 +00:00

• Target Version deleted 1.4.0

Makes sense to me. Currently you can only either load the parent form first in your controller or require_once DIR . '/ParentTable.php' in your child table, both ugly hacks. Please note that your current implementation behaves differently at least when it goes to load a form. Currently we pass an IcingaModule instance to the form through it's contructor. Happens in an ugly way, as we cannot extend Zend_Form constructor parameters.

The module is used for various context-sensitive tasks. Translation, subform loading (passing the module again) and prefix path initialization for form elements should be the most prominent ones. This behavior must be preserved, as also other modules might use forms based on this code. In that case currently translations come from the other module, while prefix paths are used from both Director and the other module.

Cheers,
Thomas

[icinga-migration]

Updated by mfrosch on 2016-11-08 09:39:03 +00:00

A missed that icingaModule attribute, should be easy to add.

Question: Which other modules use that Loader Classes currently??

[icinga-migration]

Updated by tgelf on 2016-11-08 09:56:07 +00:00

Modules providing import sources or data types might provide their own form elements. And as long as we do not either port our form back to Icinga Web 2 in some way, even completely unrelated modules like Trappola or the Cube currently base themselves on Director's QuickForm. That's all but ideal, however still better than duplicating form code everywhere.

Once we get real module dependencies we could also evaluate shipping library-only modules to isolate such dependencies. This would allow us to prototype new components in separate modules, and eventually move them to Web 2 once they have proven to be stable enough.

[Thomas-Gelf]

Thanks for the time spent on this, @lazyfrosch. I'll reject this, we'll not implement a custom loader in the Director module. Such a loader belongs to the base framework. For now, Director form and table loading works - even if it's not very "nice".

The ipl will help us to simplify some code an to get rid of most table/form aliens in the Director over time, beginning with v1.4.0. They will then make part of the library tree - and this will become a non-issue.