Good luck finding any two sources that agree on inversion of control containers. I chose the simplest definition I've found which is a dependency injection container instantiates it own objects while a service locator has them injected.themeburn wrote:Your example implementation of 'dependency injection container' is actually using $container as Service Locator, which makes the last two examples almost identical.
That means an SL can only have global objects and that all objects must be instantiated whether they're used or not. A DIC only instantiates an object at time of use and that object can be either a new instance or a shared global (the latter being useful for things like DB access). Dependency injection containers are considered preferable by many developers for obvious reasons.
-Ryan
Hello Heather,
We tried to upgrade our website from 1.5.6 to the latest but we then realized our theme doesn't have a compatible version yet. Thus, our website looks broken and the theme developer is not going to roll out a new version any time soon. (They said the upgrade requires them to re-build the theme pretty much, therefore will take a long time.)
What is your recommendation in this case? Thanks.
We tried to upgrade our website from 1.5.6 to the latest but we then realized our theme doesn't have a compatible version yet. Thus, our website looks broken and the theme developer is not going to roll out a new version any time soon. (They said the upgrade requires them to re-build the theme pretty much, therefore will take a long time.)
What is your recommendation in this case? Thanks.
This is NOT a support topic!spicyspirit wrote: What is your recommendation in this case? Thanks.
Advice: Find/hire a skilled theme builder and have them update your theme.
Norman in 't Veldt
Moderator OpenCart Forums
_________________ READ and Search BEFORE POSTING _________________
Our FREE search: Find your answer FAST!.
[How to] BTW + Verzend + betaal setup.
We are getting order view and order edit error, both are not working in opencart 2.0.2.o
arastta is the same bunch of people who got banned from OpenCart and Joomla. OpenCart's reason is simple, they published things that does not belongs to them.
http://forum.opencart.com/viewtopic.php?f=123&t=123405
http://forum.opencart.com/viewtopic.php?f=123&t=123405
ah, mind you we are going off topic here. Logic Invoice is an accounting and invoicing software to compliment OpenCart, not a shopping cart software More of an add-on / extension for OpenCart. Thanks for being our promoter though
Opencart 2.0.2.0 clean install.
I was getting the following error when going through checkout
Thanks overthroned.
I was getting the following error when going through checkout
Having checked error logs:SyntaxError: json parse error: unexpected EOF OK
So I tried this solution:PHP Notice: Error: E-Mail to required! in /home/public_html/system/library/mail.php on line 61
And it worked!overthroned wrote:Fixed it , catalog/model/account/customer.phptoCode: Select all
$mail->setSubject($this->language->get('text_new_customer')); $mail->setText($message); $mail->send();
Code: Select all
$mail->setSubject($this->language->get('text_new_customer')); $mail->setText($message); $mail->setTo($this->config->get('config_email')); $mail->setFrom($this->config->get('config_email')); $mail->setSender($this->config->get('config_name')); $mail->send();
Thanks overthroned.
you are right and i think it is again business deals for competition also i think any bug or isue fixedToo bad I see 2.0.3 is out and the only feature is another one payment module
All the Feature requests are totally ignored .
Too bad.
I hope at least the bugs which been solved are making lots of ppls happy.
you want to lie? opencart uses autloloading and name spaces for the library classes. no classes have the same name.rph wrote: No namespacing even though many classes have the same name. Watch IDEs explode when you load OpenCart.
I can add docblocks in no porblem. never needed to use a IDE that reads them though.rph wrote: [*]No docblocks. Again, IDEs can't tell what inputs and outputs should be which makes spotting bugs harder.
rph wrote: [*]Bootstrap is tightly coupled to the template instead of using a clean template and CSS preprocessor. Hope a designer never wants to do something like switch from Bootstrap to Foundation because good luck!
thats why its done via the admin and not the store front. its also how bootstrap recommends modifying the bootstrap styles. can be changed though. but really this is down to your personal preference and not an industry standard!!!
yes form builders bring more trouble than they are worth. form builders will not cover every possible scenario when you require javascript to interact with them!rph wrote: [*]Forms are all painstackingly, manually built instead of created with a form builder. No overriding or building custom forms for third-party devs. (CSRF problems still exist in the storefront because there's no unified way of handling forms.)
wasting my time!!!
in your mind againrph wrote: [*]The template box model is way too lean. There are no individual boxes within the main content so no overriding or extending there, either.
in your mind againrph wrote: [*]Inadequate separation of concerns. Things that should be their own method or classes are deeply embedded in other code. This leads to issues like DRY violations, cyclomatic complexity (nesting, nesting, and more nesting), and huge controllers which are the antithesis of modern architecture.
in your mind again. complaining about things that will cause more problems if we followed your direction of doing things.rph wrote: [*]The model layer doesn't usually return data in a usable format. Controllers are forced to manually construct the data rather than have it returned in a complete state.
just down to choice but with you something to complain about.rph wrote: [*]Almost all the object use is in the framework. There's very little in the application. (e.g. no product objects, no category objects, no manufacturer objects.)
complaining about bulls****.rph wrote: [*]PDO is completely ignored. That means compatibility with fewer database types and a huge amount of extra work manually escaping everything. Better hope third-party devs don't ever screw up and forget to escape a value.
in your mind again you magically add a new layer to the mvc structure because you have seen it done in other frameworks and think its some sort of industry standard. idiot!!rph wrote: [*]No dedicated validation layer. Everything is done ad-hoc in the controllers.
making up industry standards again!!rph wrote: [*]Modification permissions are all handled within controllers instead of being checked when the upper layers of the application detect a POST action.
just f*** off!rph wrote: [*]Significant "not invented here" syndrome in the age of Composer. Packages like Symfony's
HttpFoundation\Request are so much easier to use and feature rich than OpenCart's Request class it isn't funny. (And why the heck are we trying to build something difficult like mailing software from scratch?) Maybe we can even dream of a day when OpenCart publishes its own packages.
and yet it works!!!rph wrote: [*]There's an overly complicated SEO URL class in the app because the framework lacks a router.
in your mind!!rph wrote: [*]Still no semantic versioning after years of being asked. v1.5.3.1 is a backwards compatibility break from v1.5.3.0? Better believe it! v2.0.2.1 is next on the docket when by all accounts it should be v2.0.3.0.
in your mind!! compared to which other framework dipshit! you make stupied statements like this then you need to compare against other frameworks and apps! opencart is still much faster than magento, prestashop and every other featured packed cart out!!! do some testing instead of coming out with stupid unproven statements.rph wrote: [*]The level of dependency injection in the library suggests a number of the classes need to be rethought.
making up industry standards again!!rph wrote: [*]Internationalization is weak and incomplete. Language directories don't use ISO country codes like almost every other project in existence, zones can't be translated, numbers can't be translated, and complex problems like addressing are just ignored. Compare that with what other projects are trying to do.
in your mind!!rph wrote: [*]Text/language loading should be on the model layer, not the controller.
again you don't know what you are talking about. we hired people to do testing on the 2.0 release. some how you used your physic ability to know exactly how much testing we did.rph wrote: [*]Test coverage is low and doesn't even appear to be run before a release (if the tests even works at this stage).
expect vqmod and ocmod are nearly the same!!! again something to complain about for no reason.rph wrote: [*]ocMod is not how you do a modification system.
in your mind!!rph wrote: [*]All the mucking about with FTP for the extension system should have been an eye-opener. There's no reason to have it for anything short of an automated update system. Extensions should have been in their own dedicated directory like images.
and yet you can build your own image class with same methods as opencarts class using ImageMagik. but because i only included the GD one its something else for you to complain about. even though i dont know one host who blocks GD being used but i know many who don't include ImageMagik!!rph wrote: [*]No interfaces even though we have things like cache drivers. We could easily exchange components if we had interfaces and framework code to implement it. Change your image resizer from GD to ImageMagik. Change your captcha from reCAPTCHA to VisualCaptcha. Switch your image file handler from local to a CDN. Swap out the WYSIWYG from Summernote to CKEditor. It all could be super easy.
really dont post anything like this again!!! your just wasting my time.
OpenCart®
Project Owner & Developer.
Who is online
Users browsing this forum: No registered users and 134 guests