[#16641] - [4.0] Namespace JHtml and add support to add namespaced classes to lookup
- Closed
- 21 Aug 2017
- Medium
- Build: 4.0-dev
- # 16641
- Diff
- Digital-Peak:j4/namesapce/jhtml
- Success hound No violations found. Woof! Details
- Failure continuous-integration/drone/pr the build failed Details
- Success continuous-integration/travis-ci/pr The Travis CI build passed Details
- Success continuous-integration/appveyor/pr AppVeyor build succeeded Details
User tests: Successful: Unsuccessful:
Summary of Changes
Namespaces JHtml class and adds the possibility to add class prefixes to look for. Similar to what we did for JForm in #15893.
To showcase the whole thing the JHtmlJqueryclass got namespaced and com_content on the front and back end.
When merged, then I will port it back to the 3.8 branch.
Testing Instructions
- Edit an article on the back end
- Save and close
- Open the article on the front end
Expected result
- In the back end is jquery correctly loaded from the vendor directory when editing an article.
- The back end article lists shows the featured images/icons.
- On the front are the icons displayed to mail an article
Actual result
- jQuery is not loaded.
- The rest is working with the none namespaced code, but nothing is broken.
Documentation Changes Required
How to register class prefixes needs to be documented.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_content Front End Libraries |
| Labels |
Added:
?
|
||
brianteeman
- | Milestone |
Added: |
||
| Milestone |
Added: |
||
Any feedback here? Honestly I would like to get that into 3.8.
I like the manual registering approach, but I guess extension devs would like to get some autoload routine similar to what we have right now. I guess both can work together.
Honestly, we need to stop going with a "register X class name and Y class namespace to find classes/files in" approach system wide. Sooner or later it will cause there to be conflicts if two extensions are trying to use the same short class name which exists in two different namespaces. If someone loaded the paths for the JHtml helpers in the com_users frontend and backend, depending on what order the paths were loaded in (same will apply to namespaces), they may or may not get the correct JHtmlUsers class. The only way you can guarantee that you are using the correct class with the current setup is to be able to use the fully qualified class name when calling JHtml::_() or to have a globally unique shortcut alias which points to a single class.
Explicitly loading helpers into a registry eliminates this conflict. The only requirement that my registry has is that your class has to be loaded before adding it to the registry. With our shift to autoloading extension classes, this is a non-issue.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-08-21 14:47:09 |
| Closed_By | ⇒ | laoneo |
Any feedback here?