@brianteeman this is my idea how it should be when interacting with a component. The helpers should be replaced with models.

@brianteeman this is my idea how it should be when interacting with a component. The helpers should be replaced with models.

Without any explanation of why :(

Looks like a step towards better architecture to me. However, I would get the model in the constructor so that the (relatively) complex call only occurs once.

Without any explanation of why :(

That's not necessarily required, as there are a few obvious reasons.
a) Only models should ever interact with the persistence layer
b) Whenever you're tempted to name a class 'Helper', you're doing wrong

Looks like a step towards better architecture to me. However, I would get the model in the constructor so that the (relatively) complex call only occurs once.

The drawback is that the model is then always loaded even when no function is called.

That's not necessarily required, as there are a few obvious reasons.

obvious to you but not everyone.

Remember that there is an entire ecosphere of extension deevlopers whose only knowledge of php etc is from the joomla core. Whenever there is an architecture change it should be fully documented and explained as a reference for them AND for future contributors to the core.

For example if naming a class "helper" is doing it wrong why are there any instances of this? If it is so obviously wrong then that code should have never been meerged. Without any explanation then you are keeping secret the reason why and only an inner clique will ever be able to contribute and no one else will bee able to learn

I'v updated the description, is it more clear now?

The drawback is that the model is then always loaded even when no function is called.

Then the whole call should be moved to a private method getConfigParams() or the like.

Remember that there is an entire ecosphere of extension deevlopers whose only knowledge of php etc is from the joomla core. Whenever there is an architecture change it should be fully documented and explained as a reference for them AND for future contributors to the core.

Yes, agree. Actually that's one of the reasons for creating the RFC process (which needs to get more attention, but that's another story)

if naming a class "helper" is doing it wrong why are there any instances of this? If it is so obviously wrong then that code should have never been meerged.

Not everyone gives clean architecture the love it deserves. Helper' would be a reasonable name if one could say what one purpose a helper serves - after all, each class should serve only one purpose. But if it does, a more descriptive name for that class can always be found. Therefore, the name 'Helper' is a so-called code-smell.

Thank you