Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[4.0] Improve how ContentHelperRoute is registered #25203

Closed
wilsonge opened this issue Jun 14, 2019 · 11 comments
Closed

[4.0] Improve how ContentHelperRoute is registered #25203

wilsonge opened this issue Jun 14, 2019 · 11 comments

Comments

@wilsonge
Copy link
Contributor

#19870 namespaced ContentHelperRoute. However I still feel that this is wrong because 3PD extensions have no way of adding entries into the extensions mapper file. This file should be something that we use to allow other extensions to function who extended non-namespaced classes.

So this should probably be put in the extensions container in some way.

@SharkyKZ
Copy link
Contributor

3PD extensions have no way of adding entries into the extensions mapper file

It's meant for core extensions, according to the comment inside it.

Why not just leave components/com_content/helpers/route.php and have it extend the namespaced class. Like in com_contact. Deprecate the old classes for 5.0. The "lowercase folders in core with classes" question is hardly an issue, IMO.

@ghost ghost added the J4 Issue label Jun 15, 2019
@laoneo
Copy link
Member

laoneo commented Jun 15, 2019

Why do 3PD extensions need to add entries to the mapper file? This is only because ContentHelper is used widely in the eco system so it would crash many extensions. To be fair here, we did it only for good will as we do not have to keep BC for core extensions or I'm wrong?

@wilsonge
Copy link
Contributor Author

It's not about people using the ContentRouter file. That's fine as it is I think. There's a class alias anyhow.

But other 3rd party components will have their own router helper files probably and I don't see many places where this components/3rd party modules are different to other extensions (e.g. virtuemart or any component with a 3rd party module ecosystem etc).

@HLeithner
Copy link
Member

Shouldn't 3rd party components register the route helper while component booting or in a plugin?

@wilsonge
Copy link
Contributor Author

Well not when the components booting because you don’t wanna boot the component for smart search for example. But the auto loader doesn’t depend on that anyway.

I guess it can be loaded by the auto loader as things are. The point is any 3rd party stuff integrating won’t have the luxury of a class alias which I guess isn’t so disastrous. But certainly isn’t optimal either.

@HLeithner
Copy link
Member

Doesn't the autoloader is able to load Component<componentname>\Site\Helper\RouteHelper automatically?

@brianteeman
Copy link
Contributor

We really shouldnt be treating extensions any differently to core components. If extensions have limitations then it really defeats the point of creating an extendable system

@Hackwar
Copy link
Member

Hackwar commented Dec 28, 2020

So, 1.5 years later little has changed here. My personal oppinion is, that there is no need to change what we have right now. The alias is only there for convenience right now and we will drop that in 5.0 anyway. I would rather look at coming up with an improved component concept then, than working on this now further. Can we close this issue here?

@wilsonge
Copy link
Contributor Author

Well there's no point in working on it for J5. The point is if 3rd party extensions move to our "recommended" namespaced map then they have a hard b/c break with any extensions using their router helpers when they namespace

@ghost
Copy link

ghost commented Dec 31, 2020

should be moved to ´discussion´

@alikon
Copy link
Contributor

alikon commented Nov 12, 2022

ok i'll move it to discussion

@alikon alikon converted this issue into discussion #39199 Nov 12, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

8 participants