User tests: Successful: Unsuccessful:
Pull Request for Issue # .
As title says, this PR convert com_contact component to namespace MVC for Joomla 4.
Overall, test and make sure it works in the none namespace version of the extension
Install a copy of my branch https://github.com/joomdonation/joomla-cms/archive/namespace_com_contact.zip (to avoid problem with patchtesters component not apply patch properly)
Try to add/edit/publish/unpublish/archive contact from administrator area of the site. Make sure it is working as expected
Access to frontend of the site, look at All Front End Views module, access to all the menu items
Make sure it is all working as expected. Note on local computer, you might get the error 500 Could not instantiate mail function., it is unrelated to this PR, so ignore it (you would get the same error on none namespace version if you want to confirm)
In almost every core extensions, there are helper classes like Category Helper, Association Helper, Router Helper... Namespace these classes are easy, but we need to find a way to call the namespace classes directly in the places which it is used instead of create a none namespace class to extends that namespace class (or registering aliases). For now, I leave these classes as none namespace until we agree on a solution
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_contact Front End |
Labels |
Added:
?
|
Status | Pending | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-04-30 17:48:52 |
Closed_By | ⇒ | wilsonge |
Honestly, I think the places where we need the helpers should just try to load a class following a defined namespace pattern (eg Joomla\Content\Component\Admin\Helper\Association). If the file is in the expected place for that namespace (eg /administrator/components/com_content/Helper/Association.php) it will be found without any other code. That should be the default behavior for sure and should work already with the current autoloading behavior.
For the time being, it obviously also needs fallback code for non-namespaced extensions.
For extensions which don't follow that namespace convention, I honestly have no idea how that helper could be called. Even that autoload PR from Allon doesn't help because we don't know how the class is named in their extension. The only way is if they add some mapping as a permanent workaround which doesn't look like a great solution to me.
Or they rely on the fallback code (which eventually will be removed) and have a proxy class in the expected place.
I actually have same thinking with @Bakual. We need to have an easy way to get namespace of a given component (at the moment, it is easy via ComponentHelper - assume that namespace still stores in #__extensions table), then call these namespace helper classes directly.
Allon's PR will only help for extensions use custom autoloader. For core, I still don't see the need for it yet, plus the example you made doesn't make sense because that class although executed via outside code, still being executed within com_content, so the JLoader::registerAlias('ContentHelper', '\Joomla\Component\Content\Administrator\Helper\ContentHelper'); if needed, should be registered inside component (ie in Component Dispatcher), not in global application level like that.
I'm still confused as all hell. What are we trying to do that core needs to manually resolve namespaces or that namespaces have to be dynamically registered somewhere? Why is this just not hardcoded as a property in some class that has to be used to ensure the component classes are autoloaded?
We need to stop having magic behaviors and trying to resolve stuff except for where it is absolutely 1000% necessary and move toward explicit definitions and injection of data.
Thankyou!