Post by neufke » Mon May 04, 2015 10:43 pm

Thnx, the last one was the one i meant.

But just to give your defenition of dependency injection some comment: how many times your example is used in a correct way in OC??

New member

Posts

Joined
Sun Sep 14, 2014 9:19 pm

Post by rph » Tue May 05, 2015 5:06 am

themeburn wrote:Your example implementation of 'dependency injection container' is actually using $container as Service Locator, which makes the last two examples almost identical.
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.

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


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by spicyspirit » Wed May 13, 2015 3:29 am

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.

Newbie

Posts

Joined
Sun Apr 06, 2014 5:08 am

Post by i2Paq » Wed May 13, 2015 12:53 pm

spicyspirit wrote: What is your recommendation in this case? Thanks.
This is NOT a support topic!

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 _________________

UPGRADE to 2.x: Contemplate before thou begins!

Our FREE search: Find your answer FAST!.

BUGs?: Known BUGS for All OC Versions.

[How to] BTW + Verzend + betaal setup.


User avatar
Global Moderator

Posts

Joined
Mon Nov 09, 2009 7:00 pm
Location - Winkel - The Netherlands

Post by virgotch » Wed May 13, 2015 5:17 pm

you really belive and sure that OC 2.0.2.0 can be used in real live shop ? it is release every month with new bugs and isues because business and make money and i think OC is not open source more after 1.5.x versions

New member

Posts

Joined
Sun Oct 26, 2014 4:10 am

Post by satishkdry » Thu May 14, 2015 7:39 am

We are getting order view and order edit error, both are not working in opencart 2.0.2.o

Newbie

Posts

Joined
Thu May 14, 2015 7:29 am

Post by MarketInSG » Mon May 18, 2015 11:08 pm

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


User avatar
Guru Member

Posts

Joined
Wed Nov 16, 2011 11:53 am
Location - Singapore

Post by MarketInSG » Tue May 19, 2015 9:07 am

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 ;)


User avatar
Guru Member

Posts

Joined
Wed Nov 16, 2011 11:53 am
Location - Singapore

Post by dazoosh » Tue May 19, 2015 9:48 pm

Opencart 2.0.2.0 clean install.

I was getting the following error when going through checkout
SyntaxError: json parse error: unexpected EOF OK
Having checked error logs:
PHP Notice: Error: E-Mail to required! in /home/public_html/system/library/mail.php on line 61
So I tried this solution:
overthroned wrote:Fixed it , catalog/model/account/customer.php

Code: Select all

$mail->setSubject($this->language->get('text_new_customer'));                                                                                 
$mail->setText($message);     
$mail->send();                                                                                                                               
                                         
to

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();                                                                                                                                 
And it worked!

Thanks overthroned.

:)

New member

Posts

Joined
Mon Dec 10, 2012 6:10 pm

Post by iplocker » Wed May 20, 2015 11:19 pm

Too 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.

New member

Posts

Joined
Sun May 26, 2013 6:39 pm


Post by virgotch » Thu May 21, 2015 4:37 pm

Too 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 are right and i think it is again business deals for competition ;) also i think any bug or isue fixed

New member

Posts

Joined
Sun Oct 26, 2014 4:10 am

Post by Daniel » Tue Jun 23, 2015 4:32 pm

rph wrote: No namespacing even though many classes have the same name. Watch IDEs explode when you load OpenCart.
you want to lie? opencart uses autloloading and name spaces for the library classes. no classes have the same name.
rph wrote: [*]No docblocks. Again, IDEs can't tell what inputs and outputs should be which makes spotting bugs harder.
I can add docblocks in no porblem. never needed to use a IDE that reads them though.
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!!!
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.)
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!

wasting my time!!!
rph 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 again
rph 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
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.
in your mind again. complaining about things that will cause more problems if we followed your direction of doing things.
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.)
just down to choice but with you something to complain about.
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.
complaining about bulls****.
rph wrote: [*]No dedicated validation layer. Everything is done ad-hoc in the controllers.
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: [*]Modification permissions are all handled within controllers instead of being checked when the upper layers of the application detect a POST action.
making up industry standards again!!
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.
just f*** off!
rph wrote: [*]There's an overly complicated SEO URL class in the app because the framework lacks a router.
and yet it works!!!
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!!
rph wrote: [*]The level of dependency injection in the library suggests a number of the classes need to be rethought.
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: [*]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.
making up industry standards again!!
rph wrote: [*]Text/language loading should be on the model layer, not the controller.
in your mind!!
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).
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: [*]ocMod is not how you do a modification system.
expect vqmod and ocmod are nearly the same!!! again something to complain about for no reason.
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.
in your mind!!
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.
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!!

really dont post anything like this again!!! your just wasting my time.

OpenCart®
Project Owner & Developer.
OpenCart commercial support now available!


User avatar
Administrator

Posts

Joined
Fri Nov 03, 2006 6:57 pm
Who is online

Users browsing this forum: No registered users and 13 guests