OCMOD is back in 4.1.0.0 :)

I just received an email about the new Opencart 4.1.0.0. I have not checked it, but I smiled when I saw 'ADDED OCMOD back!!'. Why is that? Maybe because the existing module system does not work well, ha? I always knew that 'proxy' feature was garbage. Even OCMOD/VQMOD is easier and better. But Opencart has to use a power of true class inheritance!

I made 'Ka Extensions' library where this approach is implemented. Module classes can inherit functionality of Opencart files and overwrite it. A class cache is built according to rules defined by modules. In my opinion that is how a robust system should work and that would eliminate errors in ocmod patches where one module may affect another. It does not mean ocmod is bad, it works fine in some cases. The 'proxy' approach should be removed and forgotten. I would wish Opencart to start working on Opencart 5.0.x where there is no 'proxy'.

Another issue with Opencart is direct SQL queries in model files. The data should be in objects which are modified by classes and later stored in the database. I don't like adding a complex library like symphony but some kind of database object layer should be added there. That would allow to update objects at once in parent/child functions. Also, it would allow to modify queries to the database via child classes instead of patching sql queries because that patching is a quite sensitive operation and may fail after adding several modules. Partially I solved that issue with 'Query Builder' class which is also a part of 'Ka Extensions' library. But it is only for fetching the data and it does not work well with native Opencart files because that approach should be kept in mind while developing Opencart.

I wish Opencart bright future. That is why I created that post. Maybe core developers will find some interesting ideas here.

Question: How would you handle a scenario where multiple 3rd party extensions extend the same model or controller or library class, maybe even for the same method?

karapuz wrote: ↑

Tue Jan 14, 2025 1:11 pm

Another issue with Opencart is direct SQL queries in model files.

That's not an issue, that's exactly where SQL should go.

JNeuhoff wrote: ↑

Tue Jan 14, 2025 6:34 pm

Question: How would you handle a scenario where multiple 3rd party extensions extend the same model or controller or library class, maybe even for the same method?

Each module specifies what class/method they want to extend. A class cache builder collects that information and generates the cache accordingly. It means that the final code of modified files is stored in a separate directory. 'ka extensions' uses 'cache.kamod' directory for storing those class files. At the present moment it is built after 'modification' and 'vqmod' caches so they are compatible.

For example two modules extend a product controller class. The class cache builder generates the following files.
controllercatalogproduct.0.kamod.php - module 2 file
controllercatalogproduct.1.kamod.php - module 1 file
controllercatalogproduct.2.kamod.php - original opencart file
controllercatalogproduct.php - a stub file for calling by Opencart

How the stub file looks
How the original Opencart file looks in the class cache When two modules extend the same method their classes are called one by one (they have to use parent:: call of course). It is better if those modules do not depend on each other and the order is not important, but there are basic mechanisms to specify priority like build before 'before'/'after' a specific class.

I am sure there are many ways to improve that and I would like to include that (or similar) solution into Opencart instead of the 'proxy' mechanism.

paulfeakins wrote: ↑

Tue Jan 14, 2025 9:07 pm

karapuz wrote: ↑

Tue Jan 14, 2025 1:11 pm

Another issue with Opencart is direct SQL queries in model files.

That's not an issue, that's exactly where SQL should go.

The main issue with direct SQL queries that they cannot be easily modified by modules. For example, two modules add conditions on selecting a list of products. They have to patch the main SQL query in a model file with vqmod/ocmod and the patch may stop working after one module replaces a part of the query with their own code. Actually I saw a code that replaces the original SQL query completely.

Therefore for requesting the data I offer to use a query builder that will collect query information in an object (a class keeping parts of the sql query), pass that object across the code and later build the final query from that object. In that case modules may modify the query by updating that object in their own space. That will reduce a significant amount of errors in patching.

Here is a basic example:
If you don't like that it takes several lines the QB syntax may be improved to get it to one line or add parameters to QB constructor. It does not matter. The main goal is to separate building the query from executing it.

karapuz wrote: ↑

Wed Jan 15, 2025 3:47 pm

Code: Select all

$qb = new QB();
$qb->select("*");
$qb->from('product');
$qb->where('product.status = 1');
...
$result = $qb->execute();

Ridiculous.