Hi Daniel. Well done on the work you are doing.
A few queries
1) Is there any intention to load the db table names into constants to give flexibility? The code could go into db.php which is required once from index.php. Happy to help scour the files and change each db table instance to "TABLE_TABLENAME".
2) Is there any intention to place the code between "// Loader" & "// Router" in index.php into a separate file that is required once so that it doesn't get executed on each page load? Seems there is no point in re loading the settings or creating a new db class each time index.php is called for instance
3) Is there any intention to use user defined database table prefixes so that users can load opc into a shared db? I would have thought it is pretty important
4) Is there any intention to give users the option to install the app without it being pre-filled in with stuff? Perhaps two versions of the sql file could be created with one empty and the other fillied in with stuff and users can select which they want on installation. Basically opencart.sql could be cleaned up. Happy to help.
5) Is there any intention to remove the hard coded link to logo.png in the header and to allow flexible template selection?
6) It seems there are a lot of quick releases happening. This is both good and bad. Would you consider having separate "development" and "production" releases. So that at the moment, the production release would be 1.1.0 and the current 1.2.x version would be development with a numbering such as 1.2.0a to what ever which would then be periodically pushed through to production status. The current 1.2.6 would be 1.2.0f the 1.2.7 due a a few days would be 1.2.0e etc. When things get to a certain level, you could then release 1.2.0 as a production release and move the development to 1.2.1a etc.
People that install the development version would do so knowing that it is WIP and subject to frequent change while those that install the production version would see less change. just a thought.
No! this is a silly thing to do. Are you just copying OSC? I think that is the only open soucre project that does that.Dayo wrote: 1) Is there any intention to load the db table names into constants to give flexibility? The code could go into db.php which is required once from index.php. Happy to help scour the files and change each db table instance to "TABLE_TABLENAME".
Settings should not be cached as they may have some security information. The initalised classes need to be in index.php because it will be different configuration depending on the type of app you are building.Dayo wrote: 2) Is there any intention to place the code between "// Loader" & "// Router" in index.php into a separate file that is required once so that it doesn't get executed on each page load? Seems there is no point in re loading the settings or creating a new db class each time index.php is called for instance
Yes. There is a system there already, but i need to go thorugh each file and update the code aswell as updating the installer.Dayo wrote: 3) Is there any intention to use user defined database table prefixes so that users can load opc into a shared db? I would have thought it is pretty important
Maybe laterDayo wrote: 4) Is there any intention to give users the option to install the app without it being pre-filled in with stuff? Perhaps two versions of the sql file could be created with one empty and the other fillied in with stuff and users can select which they want on installation. Basically opencart.sql could be cleaned up. Happy to help.
Hard coded? it is only hard coded in the template its self. Do you mean have a upload filed int he admin to upload a new logo?Dayo wrote: 5) Is there any intention to remove the hard coded link to logo.png in the header and to allow flexible template selection?
Daniel wrote:No! this is a silly thing to do. Are you just copying OSC? I think that is the only open soucre project that does that.Dayo wrote: 1) Is there any intention to load the db table names into constants to give flexibility? The code could go into db.php which is required once from index.php. Happy to help scour the files and change each db table instance to "TABLE_TABLENAME".
I tend to agree.. I don't really see a reason to do this. Zen-cart does this too... but referring to 'order' as TABLE_ORDER doesn't buy you anything. just use 'order'
While I'll concede that you two know more about this than I do, I'll disagree. By loading the db names into a constant early in the flow, you can easily add the DB_PREFIX at the same time or make any other changes smoothly and readily.Qphoria wrote:Daniel wrote:No! this is a silly thing to do. Are you just copying OSC? I think that is the only open soucre project that does that.Dayo wrote: 1) Is there any intention to load the db table names into constants to give flexibility? The code could go into db.php which is required once from index.php. Happy to help scour the files and change each db table instance to "TABLE_TABLENAME".
I tend to agree.. I don't really see a reason to do this. Zen-cart does this too... but referring to 'order' as TABLE_ORDER doesn't buy you anything. just use 'order'
If opc had followed this approach, implementing the DB prefix would have been easy.
A simple set of edits in one file would have changed
Code: Select all
define ('TABLE_ORDER', 'order')
...
define ('TABLE_XYZ', 'xyz')
Code: Select all
define ('TABLE_ORDER', DB_PREFIX . 'order')
...
define ('TABLE_XYZ', DB_PREFIX . 'xyz')
Using variable and constants as much as possible is simply smart coding IMO.
I am only a dabbler in coding but wonder why index.php has to run the code below for instance every time it is called....Daniel wrote:Settings should not be cached as they may have some security information. The initalised classes need to be in index.php because it will be different configuration depending on the type of app you are building.Dayo wrote: 2) Is there any intention to place the code between "// Loader" & "// Router" in index.php into a separate file that is required once so that it doesn't get executed on each page load? Seems there is no point in re loading the settings or creating a new db class each time index.php is called for instance
Code: Select all
// Database
$db = new DB(DB_DRIVER, DB_HOSTNAME, DB_USERNAME, DB_PASSWORD, DB_DATABASE, DB_PREFIX);
Registry::set('db', $db);
// Settings
$query = $db->query("SELECT * FROM setting");
foreach ($query->rows as $setting) {
$config->set($setting['key'], $setting['value']);
}
I understand that doing this means changing the installer to pick one of the other. At the least then, the installation should give users a clean and empty store. I'll be happy to go through opencart.sql and clean out the stuff in there.Daniel wrote:Maybe laterDayo wrote: 4) Is there any intention to give users the option to install the app without it being pre-filled in with stuff? Perhaps two versions of the sql file could be created with one empty and the other fillied in with stuff and users can select which they want on installation. Basically opencart.sql could be cleaned up. Happy to help.
My mistake. It is hard coded in the template itself so is not an issue.Daniel wrote:Hard coded? it is only hard coded in the template its self. Do you mean have a upload filed int he admin to upload a new logo?Dayo wrote: 5) Is there any intention to remove the hard coded link to logo.png in the header and to allow flexible template selection?
Actually Daniel, it is an issue. I want to pass the store logo to the money bookers site and it seems the only way to do that is to use " HTTP_SERVER . 'catalog/view/theme/default/image/logo.png' ".Dayo wrote:My mistake. It is hard coded in the template itself so is not an issue.Daniel wrote:Hard coded? it is only hard coded in the template its self. Do you mean have a upload filed int he admin to upload a new logo?Dayo wrote: 5) Is there any intention to remove the hard coded link to logo.png in the header and to allow flexible template selection?
This means that if in future, multiple templates are available and the user selects one of those, they will have to either paste their logo into the default one as "logo.png" or have to manually edit the module file.
This is an example of why I suggested earlier that stuff should be made as constants as much as possible.
The site logo for each template could be placed in a constant and developers will simply just call this as needed knowing that the correct action will be taken.
In this instance, I would have just done "HTTP_SERVER . SITE_LOGO" and be done with it.
Who is online
Users browsing this forum: No registered users and 4 guests
