Post by JNeuhoff » Mon Apr 27, 2015 7:57 pm

rph wrote:There's nothing about it that couldn't be modernized if there was a real desire.
Why, what's wrong with the MVCL design? What exactly do you think needs to be 'modernized'?

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by rph » Tue Apr 28, 2015 2:43 am

JNeuhoff wrote:
rph wrote:There's nothing about it that couldn't be modernized if there was a real desire.
Why, what's wrong with the MVCL design? What exactly do you think needs to be 'modernized'?
Oh man, I could go on and on about that one. :laugh:

The issue isn't with MVC as a design pattern. It's having a framework/application architecture that's several years old. Just a few of the things:
  • No namespacing even though many classes have the same name. Watch IDEs explode when you load OpenCart.
  • No docblocks. Again, IDEs can't tell what inputs and outputs should be which makes spotting bugs harder.
  • 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!
  • 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.)
  • The template box model is way too lean. There are no individual boxes within the main content so no overriding or extending there, either.
  • 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.
  • 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.
  • 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.)
  • 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.
  • No dedicated validation layer. Everything is done ad-hoc in the controllers.
  • Modification permissions are all handled within controllers instead of being checked when the upper layers of the application detect a POST action.
  • 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.
  • There's an overly complicated SEO URL class in the app because the framework lacks a router.
  • 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.
  • The level of dependency injection in the library suggests a number of the classes need to be rethought.
  • 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.
  • Text/language loading should be on the model layer, not the controller.
  • Test coverage is low and doesn't even appear to be run before a release (if the tests even works at this stage).
  • ocMod is not how you do a modification system.
  • 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.
  • 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.
I'm sure there's more but those are the big ones that come to mind immediately.

Edit: Added more. ;D
Edit Edit: Even more!

-Ryan


rph
Expert Member

Posts

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

Post by kombi » Tue Apr 28, 2015 9:56 am

Is the master pending change log the correct area to see all pre-release updates? Or am I looking in the wrong place.

It seems from a PM (project management) that this should be the authoritative place to go to review all changes. I have seen way to many folks talking about the same issue. Most of the PM, change log or bug tracking software does this type of master change logs in one form or another. This help to make sure nothing gets lost and the techs are not in a vacuum or silos when making changes. I am just looking in the wrong place?

What I consider the master pending list
https://github.com/opencart/opencart/bl ... angelog.md


One of several code changes I have read that are not reflected in the v2.0.2.1 (Pending release) log that seems to have been add by one of the OC team members.
https://github.com/opencart/opencart/co ... 068e9612b9

New member

Posts

Joined
Thu Sep 06, 2012 5:03 am

Post by rph » Tue Apr 28, 2015 10:26 am

kombi wrote:Is the master pending change log the correct area to see all pre-release updates?
In as much as that info is actually kept track of, yes.

-Ryan


rph
Expert Member

Posts

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

Post by Macmarice » Wed Apr 29, 2015 1:13 am

Am new to opencart.
I have a challenge installing an extension export/import tool.
i get this error."SyntaxError: Unexpected token <
OK
<b>Warning</b>: ftp_login(): Home directory not available - aborting in <b>/home/floxells/public_html/admin/controller/extension/installer.php</b> on line <b>295</b>{"error":"Could not login as flox@floxells.com"}'

How do fix this?

Best regards.

This is NOT(!) a support topic!
Last edited by i2Paq on Wed Apr 29, 2015 2:15 pm, edited 1 time in total.
Reason: Read!

Newbie

Posts

Joined
Wed Apr 29, 2015 1:03 am

Post by neufke » Wed Apr 29, 2015 1:48 am

@rph: i think we can all state at least 10 extra lines to the mentioned list. It seems though that Daniel doesn't have the skills to implement the simplest things as cdn's or code dependencies. I do think that is the reason everyone that does a pull or even a suggestion in that direction is attacked with fill force because then is is about Daniel being an *ss, not about coding he doesn't understand. ;-)

New member

Posts

Joined
Sun Sep 14, 2014 9:19 pm

Post by rph » Wed Apr 29, 2015 2:51 am

neufke wrote:It seems though that Daniel doesn't have the skills to implement the simplest things as cdn's or code dependencies.
Clearly Daniel does. Dependency injection is already in the framework with the service locator. It's really about the desire (or lack thereof) to move from best practices in 2008 to best practices in 2015. PHP has become a very good language very rapidly. And it's going to be even better when PHP 7 comes out. Let's make use of that. We don't need a full-on Symfony bundle but we can do better than what we've got.

-Ryan


rph
Expert Member

Posts

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

Post by neufke » Wed Apr 29, 2015 5:44 am

No Daniel doesn't... and to say it with your words... using best practices of 2008 instead of... Everything is outdated but there is 1 thing i don't agree upon: switching to php7. Yes, it woul be a great improvement (hell, even 6 would be) but a sh*tload of providers are stuck in the 2004 version of php 5.2... so we would need a backwards compatibility version and each and every win of better coding is out of the window. I think we agree for the most part and i know there are serious rumours about starting a new package... lets see what the future brings.

New member

Posts

Joined
Sun Sep 14, 2014 9:19 pm

Post by JAY6390 » Wed Apr 29, 2015 5:51 am

To me, holding back on how you develop because servers need to catch up with the technology is a nonsense argument really. You're essentially saying lets not progress because servers aren't upgrading, where servers are going to be less interested in upgrading if they don't have the demand for it. It's better to use a php 7 version and force only people with php 7 to use it. Hell, if you aren't using a VPS/dedicated for your e-commerce store where you can add php 7 support/configuration then you really shouldn't be running a store. A VPS is pretty much the cost of shared hosting these days, with the added benefit of complete control. That, coupled with the fact that you can add your own security, control access to it completely and it's a no brainer that people should be on a VPS minimum. They also generally have better performance than a shared environment, no restrictions on mail per hour, subdomains, ftp accounts, database sizes/numbers

Image


User avatar
Guru Member

Posts

Joined
Wed May 26, 2010 11:47 pm
Location - United Kingdom

Post by yodapt » Wed Apr 29, 2015 6:05 am

There is no PHP 6 btw, they skipped that version for the sake of the long awaited language evolution.

VPS nowadays can be pretty inexpensive taking in account the level of control one has, so a shared VPS between a couple small or medium scaled stores sounds duable and affordable.

I would be all in exploring a OC PHP 7 version if one was to come out, not that I am expecting it to happen though.

About Dependency Injection and OC, I think at most it is a really simplified version of it, after all the Registry class is nothing more than a basic class with some magic methods to transport references of objects through OC scope. It is something people were doing before the DI concept too, and it could use some support for static objects at least.

Opencart Developer - My Extension Showcase
Contact me at aeon.yoda@gmail.com


User avatar
Active Member

Posts

Joined
Fri Jun 17, 2011 6:39 pm


Post by rph » Wed Apr 29, 2015 9:25 am

Dependency injection is just a design pattern. Its implementation is up to developers whether it's a direct class injection, a service locator, or a dependency injection container.

-Ryan


rph
Expert Member

Posts

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

Post by yodapt » Wed Apr 29, 2015 9:33 am

Yes, it's implementation in OC actually is on the same level of the framework so I guess it is enought for it's scope, but not ideal in the same way the framework isn't.

Opencart Developer - My Extension Showcase
Contact me at aeon.yoda@gmail.com


User avatar
Active Member

Posts

Joined
Fri Jun 17, 2011 6:39 pm


Post by overthroned » Fri May 01, 2015 7:49 am

Guys, does anybody has problem in 2.0.2 - when somebody registering it registers the account but trows blanc page?

Notice: Error: E-Mail to required! in /home/xxxxxx/public_html/system/library/mail.php on line 61
Last edited by overthroned on Fri May 01, 2015 8:19 am, edited 1 time in total.

Newbie

Posts

Joined
Tue Nov 25, 2014 11:11 pm

Post by JAY6390 » Fri May 01, 2015 8:11 am

overthroned wrote:Guys, does anybody has problem in 2.0.2 - when somebody registering it registers the account but trows blanc page?
Open your index.php file. Add the following on a new line after the <?php

Code: Select all

ini_set('display_errors', 1);
error_reporting(E_ALL);
Save, then register. That should show an error which you can work with

Image


User avatar
Guru Member

Posts

Joined
Wed May 26, 2010 11:47 pm
Location - United Kingdom

Post by overthroned » Fri May 01, 2015 8:20 am

JAY6390 wrote:
overthroned wrote:Guys, does anybody has problem in 2.0.2 - when somebody registering it registers the account but trows blanc page?
Open your index.php file. Add the following on a new line after the <?php

Code: Select all

ini_set('display_errors', 1);
error_reporting(E_ALL);
Save, then register. That should show an error which you can work with
Notice: Error: E-Mail to required! in /home/xxxxxx/public_html/system/library/mail.php on line 61

Newbie

Posts

Joined
Tue Nov 25, 2014 11:11 pm

Post by JAY6390 » Fri May 01, 2015 8:23 am

That means when the email is trying to send, it's not given an email address. If this is a new install/clean install then you need to register the bug on the issue tracker on github (after searching to see if anyone else has had this issue and if theres a fix)

Image


User avatar
Guru Member

Posts

Joined
Wed May 26, 2010 11:47 pm
Location - United Kingdom

Post by overthroned » Fri May 01, 2015 8:40 am

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

Newbie

Posts

Joined
Tue Nov 25, 2014 11:11 pm

Post by neufke » Sat May 02, 2015 11:55 pm

rph wrote:Dependency injection is just a design pattern. Its implementation is up to developers whether it's a direct class injection, a service locator, or a dependency injection container.
Dependency injection just a design pattern? Well, yes and no. Why re-invent multiple wheels while there some really good classes available)so if tou mean the choice between writing one's own classes or use the ones that have proved to be very good then yes, it's a design pattern... ;)

New member

Posts

Joined
Sun Sep 14, 2014 9:19 pm

Post by rph » Sun May 03, 2015 6:39 am

There's no yes or no about it. Dependency injection is a design pattern. You can directly inject your dependencies:

Code: Select all

class Controller {
    protected $request;

    public function __construct(Request $request) {
        $this->request = $request;
    }
}

$request = new Request($_POST, $GET, $_SESSION, $_SERVER, $_FILES, $_COOKIE);

$controller = new Controller($request);
You can inject them in a dependency injection container:

Code: Select all

class Controller {
    protected $request;

    public function __construct(Container $container) {
        $this->request = $container->get('request');
    }
}

$container = new Container();
$container->set('request', $container->share(function () {
    return new Request($_POST, $GET, $_SESSION, $_SERVER, $_FILES, $_COOKIE);
});

$controller = new Controller($container);
Or you can injection them in a service locator:

Code: Select all

class Controller {
    protected $request;

    public function __construct(ServiceLocator $locator) {
        $this->request = $locator['request'];
    }
}

$locator = new ServiceLocator();
$locator['request'] = new Request($_POST, $GET, $_SESSION, $_SERVER, $_FILES, $_COOKIE);

$controller = new Controller($locator);
As long as you're injecting the dependency from outside the class it's dependency injection.

-Ryan


rph
Expert Member

Posts

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

Post by themeburn » Mon May 04, 2015 9:22 pm

@rph,

Your example implementation of 'dependency injection container' is actually using $container as Service Locator, which makes the last two examples almost identical.

Also Dependency Injection and Service Locator are two distinct design patterns and not variants of the same pattern. The Service Locator is actually nothing more than a glorified Registry. The dependency injection on the other side can be manual (your first example) or achieved through a dependency injection container, which is a fairly advanced technique, used by frameworks like symfony.

My 5 cent on DI the topic.
Last edited by themeburn on Mon May 04, 2015 11:04 pm, edited 1 time in total.

Image
OpenCart themes


User avatar
New member

Posts

Joined
Fri Apr 29, 2011 8:01 pm
Who is online

Users browsing this forum: No registered users and 43 guests