FreelancePHP

1. 

   enigma1
   April 7th, 2011 - 10:45

   Mark, I believe your post is more towards PHP 5.3 than the relationship of osCommerce and PHP versions. We cannot directly control what PHP is going to do in the future or what it does now. The PHP 5.x versions introduced many OOP features from C++. Now I don’t know how many people understand that, these features are nothing new and are also optional.

   And from my experience with shopping carts there is nothing in an application, that you can achieve with PHP 5.x versions that cannot be achieved with PHP 4.x versions even now. In my view what PHP versions a host offers, should not be a problem or a factor for an osCommerce version to be released.

   So I want to ask what is the benefit of using __construct vs the compatibility constructor? What difference it makes if you are using public/protected/private member functions in a class vs plain methods. With C++ it would make a difference because of the compiler an intermediary in between source code and run time executable for large scale projects where of course you will get an appropriate error subject to the access level of a method.

   Without using a specific method prefix and before the class protection was introduced, the typical alternative was a notation for each class method to differentiate levels of access where appropriate.

   And I can go on and on with the SPL, the reflection, the predefined interfaces, abstract classes etc., but an application like osCommerce v2 or v3 doesn’t really need them because it won’t make it simpler. It will make it more difficult to manage, expand and of course to attract developers. You don’t want a core framework to be convoluted.

   At the same time the real shift of sites in general is with client side scripts. At the time passes more and more features and development will be done at the client end, with dynamic scripts and the server involvement will be minimal. WebGL is coming up and there are going to be all sorts of features ecommerce stores may benefit from it. Maybe 3 years from now? I am not sure but it will be here.

   As of the v3 when you create a new release you need to check the different environments as I mentioned on Gary’s blog, is not any good if the release works with a specific combination and configuration of SQL, Server, Browser etc. It has to work with as many as possible environments and configurations. In the old days (a decade ago) that was not much of an issue because these combinations or environments were few. But now is totally different and for websites the competition very high.
   If a customer cannot buy an item from a store because his browser is version XYZ and the framework fails to render a page, the merchant is going to be unhappy if he finds out and of course he’ll deploy another cart.

   So in my view the new osC framework misses the following:
   - Compatibility – all levels (client, server)
   - Simplicity for customizations/Code size (easier to edit 1 file than 10)
   - Utilization of code from the contributions repository
   - Client side scripts utilization
   - Documentation (functionality keeps changing significantly between releases).
   - Framework structure?

   Now a couple of points for the framework structure the so called MVC. I spend some time developing a general web-application framework using the concepts of that model and finally I gave up and never released it. The reason behind it is after significant effort (couple of years) I realized I could not do what I wanted to do.

   With MVC you can drive the framework typically by 2 main things. The request (URL, post etc) and the template. The template effectively invokes the necessary modules/code to render the page while the request parameters load the associated control part which defines and loads the various template parts.

   Ok, so during the design stage everything looked great and promising but then at the moment I started introducing the client side scripts, the dependencies between the various template modules was becoming impossible to manage. For example to click a link in one box that causes another box or section of the page to change and to cause a ripple effect among the jscripts etc. It was just not practical creating generalized code for it. I was comparing these samples against a typical MS2.2 script and in my attempt you had 10 different files opened to follow the code flow in the other with MS2.2 just 2. I would need days in development to achieve what I could with the ancient 2.2 in few hours. Plus the server resources consumed in each case. The difference was huge. And that’s the main problem with v3 also. And the use of namespaces from 5.3 complicate matters even more for a developer to follow.

   I hope the community developers realize that a web application is not about software engineering skills competition, but what they will deliver at the end of the day to a merchant or to a business so the site can last and be effective.

   So if a host has PHP version XYZ it shouldn’t be a factor for osCommerce to install it and use it. Because in a couple of years PHP 5.3 will look like PHP 4.4. Do you really care as long as the framework runs efficiently in all past and future PHP versions.
2. 

   Mark Evans
   April 7th, 2011 - 12:36

   I think your missing one big area from the compatibility question and that is namespaces, its not possible to make that backwards compatible and that was the main reason for going for PHP 5.3

   The code without namespaces was a nightmare to understand and using namespaces just made the whole framework feel more modular.

   We fully intend to make osCommerce install on as many platform configurations as possible, so far it runs on every version of PHP 5.3 and PHP 5.4 and also MySQL 4 and 5 and most likely even 6. We will support IIS and Apache, it will support running on Windows, OSX and *nix variants and we will try and support as many browsers as possible and be as accessible as possible.

   We even intend to rollout support for MS SQL Server very soon and will be easy for the community to offer PostgresSQL, CouchDB, MongoDB etc support if they so wish.

   I personally think that not supporting an EOL version of software pales in comparison to what we do support. 3.x will make the possibilities endless and in 6 months – 1 years time people won’t even remember PHP 5.2
3. 

   enigma1
   April 7th, 2011 - 13:56

   I am not sure what I am missing, what’s the nightmare without namespaces?

   In the alpha releases of v3 there was:

   class osC_Cache {
   …..

   In the current v3 there is:

   namespace osCommerce\OM\Core;
   class Cache {
   ……

   Are you saying the osC_ prefix was inadequate to distinguish core or group classes together and service various even large scale projects and there was a risk some future contribution will use osC_Cache as a separate class (or something equivalent).

   There were comments by others in the forum years ago about the number of commands to do queries to the database with the v3 framework.
   v3
   $query = $OSCOM_PDO->prepare(‘select…..)
   $query->bindInt(…..)
   $query->bindValue(…..)
   …..more binds….
   $query->execute();

   v2.2
   $query = tep_db_query(…)

   So the first thing a developer now is going to do with v3 is to deploy a tep_db_query wrapper to simplify db access.

   In my view you need to simplify the framework so it will take less time and effort to develop code with v3 than with v2.2. Once you have this abstraction level in place with generalized and useful wrappers, the database drivers underneath can follow. Same goes with the other core modules. Having to write more code lines in v3 than in v2.2 is surely not better.

   And even today I have to support sites hosting on PHP 4.x. Merchants won’t simply upgrade PHP versions on their dedicated or virtual servers neither change hosts just because PHP made another release. Their concern is to generate revenue and especially if their store is doing well the last thing they want to do is change things.

   And so I have to keep another yet configuration on my development machine for 4.4 at least, as well as for 5.3. So I am not sure when I am going to forget any of the past versions. Not anytime soon for sure.
4. 

   Mark Evans
   April 7th, 2011 - 15:49

   The cache class is quite simple

   A better example would be

   OSCOM_Site_Admin_Application_Countries_Countries::get

   vs

   Countries::get
5. 

   enigma1
   April 7th, 2011 - 18:03

   Yes which is unnecessarily complicated in the alphas and in 3.0. Why there are 52 files in 3.0 to manage countries/states on the admin? 2.2 had 2 files and say with the web 2.0 to have support with js scripts maybe another 2. In terms of code size, its over 4 times bigger than the code of 2.2 for the countries related scripts for the same functionality.

   Keep in mind for the most part editing/changing files is done remotely. The more complex directory tree there is, the longer to make a change. And to locate the right file of course.
6. 

   Mark Evans
   April 7th, 2011 - 20:33

   I am not sure that people should be suggesting the 2.2 approach to coding is the right way

   2.2 was a maintenance nightmare, it couldn’t be easily extended without hacking core files.

   The reason the code is separated is to make it extensible without hacking core and to allow developers almost limitless options in how they want to create addons, that comes at a price of added complexity. I am hopeful that when the rest of the applications have been updated and the first few rounds of automatic upgrades for core framework have been witnessed people will run screaming from 2.x into the arms of 3.x

   But to re-iterate a point i’ve made in a few different posts and forum topics, using PHP 5.3 is for sure the correct approach in more ways than I can count on both hands, the lack of wide shared hosting support at this time for me is a non argument as that will come over time. If that slows adoption of 3.x then thats a perfectly viable price to pay, people that really want it will easily find hosting to support it.

   Holding back progress because some users don’t want to upgrade isn’t an option, pretty soon a lot of other well-known projects will also require PHP 5.3, we just happen to be one of the first.

   If anyone has an argument about why PHP 5.3 isn’t a good idea that doesn’t involve the argument of lack of support I’d love to hear it!

   I would also like to point out that we have no intention of stopping support for 2.x in the near future so we will also be supporting the pre PHP 5.3 users as well, they will just have to do without the hassle free upgrades, modular architecture and whatever cool things the community creates for 3.x, surely thats a win / win for everyone? You now have 2 versions of actively developed osCommerce to choose from, if you cast your mind back a couple of years ago when very little progress was being made, I am pretty sure things are better now.

   As I think I also said on twitter a short time ago, the ingredients are ready but we still need to make the cake, anyone that wants to help will be welcomed

Leave a comment Cancel reply