PEAR

[jolt]

I am posting this to find out what the osCommerce development community's stance is on PEAR (for those of you who don't know what PEAR is, it is great! Check it out here: http://pear.php.net/manual/en/faq.php). I understand that the development roadmap entails maintaining PHP3 backwards compatibility for the 2.2 release which, while I don't necessarily agree with this decision, is commendable that the core osCommerce developers decided to keep this because they told the users that the 2.2 release would be backwards compatible - it shows dedication to the users of osCommerce because PHP4 is SO much nicer than PHP3 IMHO (I would personally be tempted to just tell people to upgrade their version of PHP). This is pertinent to the PEAR issue because almost all of the PEAR code assumes you are running PHP4 - so basically, any usage of PEAR in osCommerce implies a version that comes after 2.2 - which is probably a good thing as something like this would require some time to do :)

 

Please remember that I am posting this to guauge the reaction to the idea of such a code merge - NOT asking for free work from osCommerce developers - its just an idea, that's all.

 

There are four main reasons why I believe incorporating some PEAR into osCommerce is a good idea...

 

First, many of the goals on the development roadmap (http://www.oscommerce.com/community.php/tasks) and the TODO file distributed with downloads can be partially addressed with the use of some of the PEAR classes:

 

* Database queries as functions for database independancy (could make use of the DB database abstraction package: http://pear.php.net/manual/en/core.db.php)

 

* Update mail class requests (Could make use of Mail class(es) in PEAR: http://pear.php.net/manual/en/core.mail.intro.php)

 

* There has been requests for a template system to make it easier to modify the look of osCommerce (could use the PEAR Template code: http://pear.php.net/manual/en/packages.tem...emplates.it.php - on side note, I believe a template system should be more simple than this one - REALLY simple - but that is just me)

 

* Decent XML capabilities in PEAR (what need there is for these in osCommerce is questionable: http://pear.php.net/manual/en/packages.xml.php although Transformer and Tree can be useful, I am not a fan of the sql2xml package)

 

* There are also decent PEAR classes for payment gateways (with some still under development), paginated database results, many HTML processing classes, etc. (See it all in CVS here: http://cvs.php.net/cvs.php/pear/)

 

 

Second, PEAR development has increased a lot this year with many more developers actively working on quality control, documentation, integration of classes, etc. osCommerce could make use of their time and effort by integrating some parts of PEAR (DB abstraction might be a logical starting point?). Your going to see real changes and leaps forward in PEAR with the 4.3 release of PHP4. If parts of osCommerce used PEAR, those parts are constantly upgraded and tested by developers other than osCommerce developers - thus allowing osCommerce developers to focus more on the specifics of a commerce application and not low level code (although PHP is far from low level). This extends beyond code development and into documentation - the PEAR code is generally well documented and translated into different languages (documentation takes work).

 

Third, by the time post 2.2 releases come out, PEAR will be even further ahead than it is now (especially given its current rate of development). Therefore, some foresight and planning now can pay large dividends in later versions of osCommerce.

 

Fourth, PEAR comes with PHP so people (although they may not be aware of it), already have it on their PHP install. Users just have to make they have include_path set correctly in php.ini. The fact that it is widely distributed draws more developers towards its development and IMHO would increase the popularity of osCommerce as being a solution that integrates with the best of breeds PHP code. PEAR distributed with 4.3 and up is planned to have an update mechanism similar to that of Perl's CPAN, which will make upgrading PEAR classes very simple for osCommerce users.

 

I have used many different PEAR classes for sometime now and find PEAR to be a tremendous resource (like CPAN when I am programming Perl).

 

Anyways, here is my question: How does the osCommerce development community feel/think about exploring the idea of some PEAR integration and what good reasons are there to not include some of PEAR's functionality?

[interfaSys]

I think it would be great and make our life much simplier. The XML classes per example could help us communicate with other ebXML capable progs....etc.

 

The problem is from what I've read in the old forums that the core teams wants to develop its own tools, layers, etc. This would give them more control on every aspect of oscommerce.

 

Why not..but it takes time.....way to much time imho.

[jolt]

Having complete control over osCommerce development is of obvious value to the core developers. IMHO, I don't think using PEAR takes this control away though. For example. lets take database abstraction: osCommerce could use DB.php and get the benefit of being easier to port to different database platforms and have many useful data manipulation methods. I don't see how using something like that takes away control due to its low level implementation.

[Harald Ponce de Leon]

I can see where Pear can benefit on some feature or function sets, but also where its a definite no-no on other sets.

 

There hasnt been a need to use Pear as of yet for any sort of functionality.

 

For the template issue, a template engine will not be implemented at this time into the codebase, but a template structure will. This will make it easy for people to add their own template engines which meet their requirements - if at all.

 

For the database independency issue, there hasnt been much discussion on this but the idea is to implement it to a style similar to the languages structure, which allows us to call functions that then call native database queries taking advantage of its offerings (stored procedures, transactions, subselects, etc).

 

Using templates or database independency "engines" has good and bad points to it. Its good for the general solution being offered (commercial or free) but how many times will a store change its layout? Or how many times will it change its database? All this work needs to be parsed on each request made to the webserver - for what reasons? So in two months time you can say 'I am sick of mysql, lets use postgresql' or 'I dont like the box on the left side, lets move it to the right side'.

 

Post 2.2 development will be a fun experience, which is why its kinda slow at the moment as the dirty work needs to be done first :D

[interfaSys]

So if PEAR can benefit on some feature, then we can start implementing those features :)

 

About templates, I agree that a fixed template engine is not needed but I can't wait for a real template structure, we have to build our own right now. I don't agree with your template engine's example of use. A template allows for much faster developpement time, it's not a question of changing the design every other day. It can be usefull to show different designs to a customer (done in less time).

 

About the database, I'd rather have a top notch function set for every database (your suggestion) than a general engine that would be offering less performance, but are there some benchmarks somewhere? Is it really worth developping? Can't wait for the SAPDB driver (http://www.sapdb.org) :D

 

Right now, we call fields by their name and this has a speed penalty (If I remember correctly), would using a layer really make it worse?

[jolt]

I think you have both made some excellent points. First, I would like to reiterate that the main focus of my original post was to find out how open the core developers were to incorporating PEAR components into osCommerce since I believe that PEAR has a lot to offer and will have a lot more to offer in the very near future. I am glad to see that there is some openness to this idea - at least there seems to be. Obviously, you don't want to throw extra code at a project unless it offers a substantial advantage. I would much rather have a lean and fast set of source than a bloated and slow set of source whereby both sets did the same thing. My original examples (database abstraction, templates, mime email, xml composition/parsing/manipulation) were basically just that - examples of what PEAR can provide. Does osCommerce need/want all of them - NO! ;) But I am glad to see that there is some openess to the benefits of PEAR.

 

I think Harold makes an excellent point by noting that there is much work to do before integrating this code so lets not get to distracted by planning future development efforts. I think it is good to focus on the task at hand and not speculate too much on future plans. My reason for bringing this issue up in the first place is because I am considering using osCommerce and I want to be sure that the developers would be open to the code that I would contribute to the project. It wouldn't make much sense for me to get started and then have people telling me that they did not agree with what I was doing.

 

Now, let me try to make a case for database abstraction. Why would we want this? Several reasons come to mind - but lets start with the most important:

 

1) Wider potential user base of osCommerce if it runs on other database systems

 

Many people don't run MySQL (I do and I love it) - they may really like PostgreSQL or maybe they like Access. Many times, a company will force developers to use a specific database platform regardless of what the developers want to use. If osCommerce is to gain wide acceptance, IMHO, it will need to interoperate with many database systems.

 

2) Database systems differ widely in their implementation

 

Most major database systems at this point in time follow the ANSI 92 SQL standards (even Access XP now). Unfortunately, you are rather limited by what you can do with ANSI SQL. The main parts where you get screwed when transferring to a different database platform are datatypes (a decimal column over in the new database is handled differently), features implemented (i.e. sub selects, stored procedures, and views don't work in MySQL), and especially functions (i.e. the only functions you can count on are NOW(), COUNT(), SUM(), AVG()). Want to see how close your queries are to ANSI, simply restart the MySQL daemon in ANSI mode.

 

3) The database drivers that can be compiled/loaded into php differ widely in implementation of minor details

 

This is the real killer. Lets look at a few examples... First we take MySQL and Oracle connection functions:

 

MySQL:

 

resource mysql_connect ( [string server [, string username [, string password [, bool new_link [, int client_flags]]]]])

 

Oracle:

 

int ora_logon ( string user, string password)

 

As you can see, connecting to the database server (this is just the beginning keep in mind - have not even got to running queries yet) is done completely different. Both functions don't even take the same number of parameters AND don't even return the same data type. This is the case will ALL database drivers in PHP. OR, we could not worry about it and connect to them all the same way: http://pear.php.net/manual/en/core.db.tut_connect.php.

 

Now lets look at running queries... First we take PostgreSQL and Interbase query functions:

 

PostgreSQL:

 

int ibase_query ( [int link_identifier, string query [, int bind_args]])

 

Interbase:

 

resource pg_query ( resource connection, string query)

 

They don't return the same datatypes and the Interbase function takes an extra parameter - this is because with Interbase, you generally prepare a SQL statement and then excecute it: int ibase_execute ( int query [, int bind_args]). By preparing statements, you allow the database server to only compile the SQL statement once and then bind arguments to the query to run multiple queries with one compile operation. Or you can query all databases the same way: http://pear.php.net/manual/en/core.db.query.php

 

Now lets finalize our examples with one that hits home for MySQL users: absence of auto_increment columns in major database platforms... Most major database platforms rely on sequences (i.e. PostgreSQL, Oracle, etc.) as opposed to auto incrementing by adding 1 the the last insert id. This can be problematic when porting MySQL applications that rely on this functionality. You can hack it sometimes with a sequence combined with a trigger, but why not use an abstraction layer that already has this taken care of: http://pear.php.net/manual/en/core.db.nextid.php and have it emulate sequence functionality for databases that don't support them (i.e. MySQL).

 

 

 

As you can see (you are only seeing the tip of the iceburg here - believe me I know), supporting multiple databases is a real hassle if you don't use an abstraction layer. I am not suggesting that you abandon your idea:

 

"For the database independency issue, there hasnt been much discussion on this but the idea is to implement it to a style similar to the languages structure, which allows us to call functions that then call native database queries taking advantage of its offerings (stored procedures, transactions, subselects, etc)."

 

I am suggesting that we consider intergrating a well tested and distributed abstraction layer to deal with all the minor details and provide osCommerce developers with a unified API for accessing database information. By using consistent data access methods, it helps ensure that someone who is working on a Oracle database can contribute code that will also work for MySQL lovers (i.e. me) and vice versa. It is reasonable to assume that people will extend osCommerce by running additional queries to do different useful things - wouldn't it be great if they could all swap code without worrying about what database the other user was running? And all of these users already have the code for this abstraction on their system AND have the documentation online and translated into different languages.

 

Now Harold makes an excellent point here: "All this work needs to be parsed on each request made to the webserver - for what reasons?" Adding a database abstraction layer has compile time expense. IMHO (based on experience and benchmarks) the expense is minimal AND for anyone who is serious about commerce, it be eliminated through using a byte code caching mechanism like this one (I use this myself): http://www.php-accelerator.co.uk/

[jolt]

Weirdlab,

 

I don't use SAPDB, but have read it is pretty cool. I have a hard enough time keeping up with PostgreSQL and MySQL. SAPDB does support native ODBC connectivity; therefore, all of these functions: http://www.php.net/manual/en/ref.odbc.php will work with it. Please note that when I say it natively supports it, I mean it was programmed with ODBC in mind from early on and it will therefore not suffer from the performance issues that you will see when using ODBC middleware like MyODBC: http://www.mysql.com/downloads/api-myodbc-3.51.html.

 

On a side note, you could use DB.php to talk to SAPDB (using the ODBC driver) and then your code would be much more portable to other database platforms.

[stng]

I agree that database abstraction is a good thing to add. The benchmarks I've seen have shown that a good abstraction layer adds very little overhead. It's worth it not because users will switch databases after they setup a store but because it allows users to run with OS Commerce with other databases if it makes sense.

 

I'm also +1 on the notion of a templating system because it speeds along customization/development of sites. In particular, there's a lot of code housed inside the pages still that really makes it difficult for designers.

 

That said, I'd like to reiterate that I'm very happy with OS Commerce. It totally rocks! But if we can make it better, we should. :)

 

-- stan c",)

[jolt]

There seems to be a lot of discussion over including a template system for those designer types. I understand the need for this I suppose - I think programmers and designers use different sides of the brain. I am sure that the core osCommerce developers have some good plans for this. I do not like the template system that comes with PEAR (but I like almost all the other code in PEAR). I personally think any template system should be pretty simple given that PHP itself it a sort of macro template processing language. Anyways, here is a real simple template system addon that you could use until the core developers come out with their solution for osCommerce - simple and real fast (PHP 4 only - sorry but you can't easily hack on a seemless template system in PHP 3):

 

View and follow directions given here (you can copy/paste this page):

 

http://caffeine.contactdesigns.com/~jolt/s...mplate_code.php

 

I have not actually installed osCommerce yet ;) But I have read the majority of the code. If you have problems getting this to work, it is probably because I could not adequatley test it. If this is the case, let me know and I will install osCommerce and fix it. I generally get pretty close to right the first time around though so there probably won't be any problems with it (famous last words).

[humaneasy]

About Templating Systems I have a link with benchmarks of several of those that sit around and I can tell you that PEAR is very bad.

 

The discussion about this is spread all around this forum and mainly in the old developers mail list.

 

I proposed the use of Modelixe (http://modelixe.phpedit.com) because it's fast, XML compliant (with out being XML) and it has a plug-in developed to DreamWeaver (one of the most used web designer's program)... and it's LGPL. Give it a look.

 

About ADOdb I must make here a BIG correction: It's BSD-licensed :oops:

 

I let you here a few OLD links about all this stuff:

 

Proposals for next CORE version

 

New template system

 

1,

 

8) Lopo

[jolt]

I have never been crazy about the PEAR template systems. I will have to check out that Modelixe one. Their site appears to be down now so I can't really make a comment. I personally have always been pro sticking with simple variable substitution with namespace functionality to not have to worry about blocks and then using alternative control structure syntax to provide advanced looping support (everything PHP supports). Using the alternative syntax makes it easy to have it display well in WYSIWYG editors. This way, it is much faster than any template system out there because it is bascially bare bones - plus I have no real desire to learn a new coding style for the template system (i.e. Smarty).

 

I am pretty much open to any template system so long as it is simple, fast, and hopefully OO. On the DB abstraction side of things I still prefer PEAR's DB.php over ADODB. What is the hesitation over use of the PHP license anyways?

[henri]

Database abstraction is a good thing. I normally use the php-Lib classes.

 

The main problem is, it costs time. I would find it better to simply include a db file with the native functions.

 

Look at the Benchmarks:

http://phplens.com/lens/adodb/

Don't know if pear is faster now, cause the last time i looked at pear was when i made the decision which db-abstraction layer i wanna use for my projects (i took phplib, only one file to include)

 

If you look a http://www.phprojekt.com/ it supports 5 DBs with no abstraction. (i would say inefficient code, but very simple stricted -> fast)

Cu Henri

 

Template System:

It would be great to have one :) -> but if the shop has to parse the template it also costs ressources. (Ok computers are getting fast today)

 

Perhaps there shoul e some Benchmarktesting bevor implenting it.

 

Cu Henri

[Jan0815]

PEAR has one BIG disadvantage. PEAR is licensed under the PHP-License. The PHP-license ins incompatible with the GPL.

 

If we use PEAR code we will have to ask all contributors if they are willing to release that code to us under GPL.

 

Please always pay attention to the licenses ;-)

[humaneasy]

Database abstraction is a good thing. I normally use the php-Lib classes.

 

The main problem is, it costs time.

 

Give ADODB a try :)

 

Template System:

It would be great to have one :) -> but if the shop has to parse the template it also costs ressources. (Ok computers are getting fast today)

 

Cu Henri

 

But how much, much, easier it will be to do something like this from osCommerce :roll:

 

8) Lopo

[henri]

Database abstraction is a good thing. I normally use the php-Lib classes.

The main problem is, it costs time.

Give ADODB a try :)

Too late;

I took phplib (LGPL), cause it has some other usefull features (templatesystem) too.

And at that time i didn't know ADODB and the benchmarks.

[jolt]

Hmm - it was a bad idea of me to propose use of PEAR due to licensing issues. DOH!!! :?

 

Didn't realize there were incompatibilities with PHP amd GPL given that PHP itself is licensed under PHP. I guess I need to read the fine print.

 

Well for what it is worth, I am still pro a DB abstraction layer - go ADODB!!!

 

Regarding the templates, I don't care too much about it personally - but I DO think that having an easy to use template system would expand the reach of osCommerce quite a bit by making it easier for graphics/wysiwyg people to adopt. I don't like the real complicated template systems that have their own markup for loops etc where they try to reinvent another language.

 

One word of advise considering the ADODB benchmark results: consider the source of the information :D That being said, I think ADODB is fairly solid - it is battle proven, has active development, and a wide user base.

[Guest]

Hmm - it was a bad idea of me to propose use of PEAR due to licensing issues. DOH!!! :?

 

Didn't realize there were incompatibilities with PHP amd GPL given that PHP itself is licensed under PHP. I guess I need to read the fine print.

 

Why would the PHP license cause any problems? As far as I can tell there's no problem as long as you don't redistribute PEAR itself.

I would really be depressed if I misread/understood the license, because I am working on getting 2.2 to work through PEAR::DB atm.

 

 

Regards,

Rob

[MrBafner]

Fatal error: main(): Failed opening required 'includes/languages/.php' (include_path='.:/usr/share/pear')