Page 1 of 1

Why hardcoding template / views related stuff in controller ?

Posted: Wed Apr 22, 2020 9:48 pm
by Saahib
Hi,
I can see that OC3 comes with lots of functionality by default however, I decided to make some cosmetic changes as well wanted to remove some bloat (things I don't want (like unwanted JS etc.).
Since, OC says itc MVC-L , I thought, it will not be hard to do it as its already MVC but then right from start, I see that catalog/controller/product has got hardcoded JS files. Aren't they are supposed to be added via templates (views) . And if a module needs them, should be dynamically added.

I was thinking to upgrade to BS4.3 and now I can't change without messing with core files.

Re: Why hardcoding template / views related stuff in controller ?

Posted: Wed Apr 22, 2020 9:51 pm
by straightlight
I was thinking to upgrade to BS4.3 and now I can't change without messing with core files.
That is because core files don't need to be edited. Rather using OCMod or VQMod without the cache storage version could still achieve what you need.

Re: Why hardcoding template / views related stuff in controller ?

Posted: Wed Apr 22, 2020 9:59 pm
by Saahib
Its not about what I want to achieve, Its about the choices being made here. Isn't hampering the whole idea of MVC by hardcoding those files there.

Re: Why hardcoding template / views related stuff in controller ?

Posted: Wed Apr 22, 2020 10:09 pm
by straightlight
Saahib wrote:
Wed Apr 22, 2020 9:59 pm
Its not about what I want to achieve, Its about the choices being made here. Isn't hampering the whole idea of MVC by hardcoding those files there.
Based on an idea of a creator where a default theme is being used, his idea on dynamically load JS files from the controllers is to provide the idea to other extension theme developers to ensure the compatibility of the required features into custom themes in the mean time. In other words, while OC users are still entitled to load their JS files manually from their header.twig file, it does not prevent them on working with any JS as long as they know what they're doing. In the end, it comes to a development standpoint rather than originating from the users who are typically trying those codes. On the other way around, from one location where those extensions might actually work, buyers could still end up with different results between servers at some point where those reported issues may not be replicated or based on the ways its been addressed by the OP users on the forum in order for the OC team to be able to replicate the reported issue.

Re: Why hardcoding template / views related stuff in controller ?

Posted: Fri Apr 24, 2020 2:37 am
by Saahib
Alright, I will not be complaining here more as clearly its perceived that its best. Being open to discussions and ideas is just first step towards real FOSS.
See, with my limited knowledge, first of all those JS selected are bloated for the task they achieve, secondly they could be loaded dynamically where they are actually needed ie. not just loading even if not need. This approach is good for prototyping but not production.

But I understand, no further discussion, what already is implemented is best . Period :-) .

I will rather save your energy for topics where I will actually need your guidance and your precise pointers.

Re: Why hardcoding template / views related stuff in controller ?

Posted: Sat Jul 04, 2020 2:01 am
by jrr
straightlight wrote:
Wed Apr 22, 2020 9:51 pm
I was thinking to upgrade to BS4.3 and now I can't change without messing with core files.
That is because core files don't need to be edited. Rather using OCMod or VQMod without the cache storage version could still achieve what you need.
Aren't OCMod and VQMod being discouraged in extensions? I see a number of developers saying that.

If so, why would it be a good idea here? Still trying to figure out OC...

Re: Why hardcoding template / views related stuff in controller ?

Posted: Sat Jul 04, 2020 9:54 am
by IP_CAM
Aren't OCMod and VQMod being discouraged in extensions?
Well, VqMod has been a simple and comfortable way, to add/change something
to/in OpenCart, without touching OC Soure Code itself. OcMod has actually been
planned and installed from OC Version 2.0 up, to replace VqMod, for what reason
ever. But VqMod was still not dropped, but further offered by Dev's, and many OC
Users installed it again in v.2+/v.3+ Versions, and bought Extensions. But since
VqMod and OcMod cannot 'communicate' with each other (kind of :D ) , as they
come by default, it lead to many problems, up to today.

JNeuhoff's Integrated VQmod for OpenCart solves most of those problems,
by also placing VqMod Content in the DataBase, like OcMod does. It makes it much
easier, to so have a Extensions 'shown' in one place in Admin Tools. And it's useful,
because OcMod has some (unknown to me) limitations, since not all Extensions
seem to work, if coded the 'OcMod' Way of doing things:
https://www.opencart.com/index.php?rout ... n_id=19501

Both Routines will (officially) be dropped in the next official OC Release, as
I have been reading about, and replaced by something, probably quite similar to this:
https://www.opencart.com/index.php?rout ... n_id=29092
but at least VqMod will probably further exist, as I expect ... :laugh:

Just to give you some idea on this all. 8) Whatever OC does, some will like it, and some not ...
Ernie