I might get some more ideas from the kohana project, a PHP framework. Its core conists of directories for implementing a model-view-control framework, and then it provides an 'application' directory with similar sub-directories where application-specific files (of same name than the core-files, with even the same methods) can be specified. They call it cascading resources, it works, because I have used it myself. But I don't know how they do the magic. See e.g. http://upload.wikimedia.org/wikipedia/e ... odules.png
If we could create something similar for OpenCart that would be great.
Not quite, see my previous message. How does Contrib-B know which class (those from Contrib-A, Contrib-whatever, or the original OpenCart Class) to extend when it is not aware of any of the other contributions?Luvz2drv wrote: Basic OOP -- inheiratance... of one class to another... where you can override methods from the child class. or give new ones.
Override Engine * Integrated VQMod * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Rich Snippets * Google Tag Manager * Export/Import Tool * SpamBot Buster * Survey Plus
Kohana system is not directly a inheritance it is mainly a system like PATH variable.Luvz2drv wrote: Basic OOP -- inheiratance... of one class to another... where you can override methods from the child class. or give new ones.
Kohana use a list of paths (current directory + user defined paths in a config file + system path) to look into when a new class is detected (autoload redefined). It is then possible to extends or modify a view, a model, a controller, a library, a module at many levels of a tree of directories. Anything except the core system files (5 files).
Kohana framework could be an option for the development of opencard. Why not ?
I have no idea what opencard is ... but opencart i do! 
jk i think the framework that is here is great and we don;t need to rely on other code bases for our cart.
my 2cents
jk i think the framework that is here is great and we don;t need to rely on other code bases for our cart.my 2cents
Alain91 wrote: Kohana framework could be an option for the development of opencard. Why not ?
First off, it's worth noting that Daniel is working on a different structure for v0.8, I'm not quite sure how he intends to tackle this issue, but then I'm not quite sure what the issue is.
What is it you are actually trying to achieve, and why?
Maybe once we have the basics, rather than a proposed solution we'll be able to reach the destination quicker...
What is it you are actually trying to achieve, and why?
Maybe once we have the basics, rather than a proposed solution we'll be able to reach the destination quicker...
Well, after discussing with Daniel, things are indeed quite different for 0.8, and some of the changes basically negate the idea of a "template override" system, however a simpler "override" folder could give the same results.
The "simple" idea that started this thread was meant to avoid all the manual edits by allowing the use of "drop-ins" that would override the "core" files without editing or deleting them. This makes it easy for store owners to add and remove contribs to see if its what they want.
Example:
If you made a contrib that makes changes to: "catalog/controller/product.php"
You would make your contrib directory structure: "catalog/controller/override/product.php"
As the controller.php file loaded each controller file, it would first check if an override existed in the override folder. If yes, then override, if no, then use the default.
The same would apply to language files, library files, and template files, including images and css. The override file would always be one level lower than the file being overridden.
- Now in 2 months if there is a new version of the contrib, you can simple drop the new files over the other override, leaving the core files intact.
- And in 3 months if there is a new OpenCart, you can just upload it over the other core files, leaving the overrides intact
If the contrib breaks something, then its as simple as removing the override files. If the new OpenCart version is transparent to the changes, then there is nothing more needed to be done to get your contrib working again. Win-Win for all! Plug n Play!
The only limitation here is that if 2 contribs modify the same file, which can either mean:
A) they are 2 conflicting contribs, which wouldn't matter since you'd only use one or the other.
Or
B) there are 2 different features being changed in the same file, which would lead to some minimal manual edits.
It's not perfect, but much better than the existing method.
This then led into a deeper discussion of more "modular" files that could be "wrapped" into a single wrapper file as shown in the Kohana example.
So my first achievement is to implement an "override" folder system. Followed by something more exquisite like the kohana system.
The simple "override folder" design CAN be accomplished as a contrib (I already have it 95% done on my dev site), but it would need the community to follow the rules on how to use it, which is why it would be best as a core official development design.
The "simple" idea that started this thread was meant to avoid all the manual edits by allowing the use of "drop-ins" that would override the "core" files without editing or deleting them. This makes it easy for store owners to add and remove contribs to see if its what they want.
Example:
If you made a contrib that makes changes to: "catalog/controller/product.php"
You would make your contrib directory structure: "catalog/controller/override/product.php"
As the controller.php file loaded each controller file, it would first check if an override existed in the override folder. If yes, then override, if no, then use the default.
The same would apply to language files, library files, and template files, including images and css. The override file would always be one level lower than the file being overridden.
- Now in 2 months if there is a new version of the contrib, you can simple drop the new files over the other override, leaving the core files intact.
- And in 3 months if there is a new OpenCart, you can just upload it over the other core files, leaving the overrides intact
If the contrib breaks something, then its as simple as removing the override files. If the new OpenCart version is transparent to the changes, then there is nothing more needed to be done to get your contrib working again. Win-Win for all! Plug n Play!
The only limitation here is that if 2 contribs modify the same file, which can either mean:
A) they are 2 conflicting contribs, which wouldn't matter since you'd only use one or the other.
Or
B) there are 2 different features being changed in the same file, which would lead to some minimal manual edits.
It's not perfect, but much better than the existing method.
This then led into a deeper discussion of more "modular" files that could be "wrapped" into a single wrapper file as shown in the Kohana example.
So my first achievement is to implement an "override" folder system. Followed by something more exquisite like the kohana system.
The simple "override folder" design CAN be accomplished as a contrib (I already have it 95% done on my dev site), but it would need the community to follow the rules on how to use it, which is why it would be best as a core official development design.
Last edited by Qphoria on Fri Sep 05, 2008 3:24 am, edited 1 time in total.
Who is online
Users browsing this forum: No registered users and 4 guests
