OpenCart Community

As I have gone about developing my first ocmod, one thought popped into my head, "Oh my goodness, they've reinvented the diff-patch but this time in the worst possible way: XML! [gag, vomit]"

Using a real diff-patch allows for things like popular version control software to generate the ocmod. Git and other version control tools do diffs natively. The XML file is still potentially useful for the metadata about the extension but you might as well use JSON for the metadata once you drop the rest of the data into a diff file.

An even better solution is to burninate all the existing .tpl's and generate arrays of information. Those arrays are then used to construct the page and results in almost no HTML in the .tpl files. Then build out a plugin system that lets users hook the (1) start of each function, (2) modify content prior to output, (3) modify .tpl each array, and (4) finally hook the end of each function. Then there will be almost no need for ocmods at that point.

Well spoken, you are not trying to re-invent the Wheel, you are trying to re-invent OC !
In addition, if no more (paid) Mod's would be needed, who in the world, from the viewpoint of a DEV,
would care about OC any longer ?

The OC Idea serves a purpose, it's not just another combined work of Fan's, and Freaks,
trying to have a good time. It's hard work, and hard money, involved, to make it work,
and to keep it going.

But there is nothing in the way, to take/use OC, as bases, to create 'your Idea' of Software.
And if you succeed, you'll find out, probably, that it just makes very little sense, to just throw it
onto the Open Scene, without at least a TAG on it, in some way, and just, to feel good.
Possibly, about 0.5 Percent of Downloaders would donate, a few bucks, possibly, but the
majority would try to make a buck, in either way, by use of your Work. After all, it serves it's
sole Purpose, namely, to make Sales, and so Money, for everybody, involved...

But as soon as you depend on such a DEV-Setup, you are not longer free to decide, what to change, or
do in another way, without risking the whole System to get damaged, as a consequence of such doing.

as I look at it, at laest, by not beeing involved, or bound, in any form...
Good Luck
Ernie
hitline.info/shop/

IP_CAM wrote:Well spoken, you are not trying to re-invent the Wheel, you are trying to re-invent OC !

...

as I look at it, at laest, by not beeing involved, or bound, in any form...
Good Luck
Ernie
hitline.info/shop/

Your reply was absolutely and completely incomprehensible. Are you drunk/high?

I manage a heavily-modded OC 1.x install that has moved millions of dollars worth of merchandise during its existence. The software hasn't been upgraded in 5 years because upgrading is quite literally impossible due to all of the modifications made to the core to make it barely passable as an ecommerce solution. Looking at my upgrade options, OCMOD and VQMOD can theoretically let me apply the modifications I use after investing a lot of unnecessary labor. VQMOD is fundamentally broken because it basically reinvented the wheel that's been solved since about 1985 (i.e. 30 years ago). OCMOD adopted VQMOD's broken solution, made it less capable, and is therefore even more fundamentally broken than VQMOD.

This thread is to discuss transitioning to a sensible diff-patching system and/or dramatically extending the existing event/plugin system instead of the currently insane XML-based approach. There is at least one drop-in-ready PHP diff-patch library out there. Please stay on-topic.