Why not just break it into tabs like OpenCart does for products or store settings?affect wrote:Not really outside, mostly when splitting module config into parts. Let's say I have a module that has multiple logical configuration parts, for example it has some configuration variables, positions (layouts) and beside that it lists and allows adding/removing records from the database.Out of curiosity, why do you think this is an issue? The only time I can see this adding work is if you want to make a change outside the extension.
-Ryan
I don't think that this idea is about layout but rather how the database is actually setup (not sure if this is the right word).
[setup? designed?
Basically trying to find the word that describes how you actually decide what database type and if use indexes, and/or foreign keys.]
Something like this comes across as very minor and actually non-relevant in most cases but this is being caused by a much larger issue of how the mysql db class and database is designed.
However, I can see that fixing this would be a huge undertaking! Thereby, loosing the ability to replace is a very fair trade off.
[setup? designed?
Basically trying to find the word that describes how you actually decide what database type and if use indexes, and/or foreign keys.]
Something like this comes across as very minor and actually non-relevant in most cases but this is being caused by a much larger issue of how the mysql db class and database is designed.
However, I can see that fixing this would be a huge undertaking! Thereby, loosing the ability to replace is a very fair trade off.
930sc ... because it is fun!
yea.. universal model functions would be good
Code: Select all
function updateTable($table, $column, $value, $clause) {
$this->db->query("UPDATE " . DB_PREFIX . "$table SET `" . $column . "` = '" . $value . "' WHERE " . $clause);
}
Actually I haven't looked at how tabs are coded yet, but that might be a great idea (if it doesn't split the module into even more files. It was a pain for me coding modules in the OC mvc+l way, actually, got used to Presta's way of separating modules from the core architecture and making it available to put all belonging files in one folder).rph wrote:Why not just break it into tabs like OpenCart does for products or store settings?
I'll check tabs out when I return from my trip next week, thanks.
Tabs will help you organize your pages better, but I don't seem to recall them being individual entities within the main section. So, you still need to do delete and add.
MVC vs monolithic is another topic on it's own.
Personally, monolithic is like php3
However, a monolithic structure does allow you to do plugins relatively easy. But then again, this can be done with MVC if the bootstrapper/main controller was built that way.
MVC vs monolithic is another topic on it's own.
Personally, monolithic is like php3
However, a monolithic structure does allow you to do plugins relatively easy. But then again, this can be done with MVC if the bootstrapper/main controller was built that way.
930sc ... because it is fun!
Yep, that's kind of how it's done in Presta. Modules are still mvc-like, although the files are stored in a same folder which makes it easy to develop and add/delete. Really convenient.Personally, monolithic is like php3
However, a monolithic structure does allow you to do plugins relatively easy. But then again, this can be done with MVC if the bootstrapper/main controller was built that way.
Agreed, hence my restructure proposal in OpenCart 2.0affect wrote:Yep, that's kind of how it's done in Presta. Modules are still mvc-like, although the files are stored in a same folder which makes it easy to develop and add/delete. Really convenient.Personally, monolithic is like php3
However, a monolithic structure does allow you to do plugins relatively easy. But then again, this can be done with MVC if the bootstrapper/main controller was built that way.
http://forum.opencart.com/viewtopic.php?t=28787
Well this doesn't really cover core libraries, only had Extensions in mind for this. Extensions are self-contained anyway. If it is done right, extensions would not even be in the same area as core libraries and they could be structured however they like.rph wrote:The problem with that is it pretty much kills any practical sharing of functions. You'd end up putting duplicate code in all over the place.
And don't get me started on duplicate code..considering the mess of dupe code we have already. Trust me that's the last thing I want.
Hi,
Was thinking about the OpenCart release cycle, and i think this model would greatly benefit the process.
HotFixes are go
http://nvie.com/posts/a-successful-git-branching-model/
https://github.com/nvie/gitflow
What u guys think?
Greetings
boriscm
Was thinking about the OpenCart release cycle, and i think this model would greatly benefit the process.
HotFixes are go
http://nvie.com/posts/a-successful-git-branching-model/
https://github.com/nvie/gitflow
What u guys think?
Greetings
boriscm
Hi guys,
Sorry I'm a new programmer trying to write my own modules. I'm trying to learn more about Opencart's setting table and saw this line of code.
I don't know if I understood the code correctly. Does this mean that everytime you save the settings, the old settings are deleted before the new settings are entered?
Is there a possibility that this will cause a scenario where after the delete is done, the insert fails due to some reason and you lose the settings?
Sorry I'm a new programmer trying to write my own modules. I'm trying to learn more about Opencart's setting table and saw this line of code.
Code: Select all
$this->db->query("DELETE FROM " . DB_PREFIX . "setting WHERE store_id = '" . (int)$store_id . "' AND `group` = '" . $this->db->escape($group) . "'");
foreach ($data as $key => $value) // Code for inserting continues here.
Is there a possibility that this will cause a scenario where after the delete is done, the insert fails due to some reason and you lose the settings?
Who is online
Users browsing this forum: No registered users and 28 guests