Hmm, lot's of good posts on here. I've been missing out because my router decided to block devnetwork.net for some reason. I'm bypassing it so I can access the site right now.
First things first, we still need a project leader, or at least someone who can act as a consultant to keep us all on track. I'd nominate myself, but I'm sure there are others here that have developed large applications such as this before that would be better suited. If this isn't an option, then we will just collectively make decisions. Popular vote will rule.
System Name
I'm going to sit on the name for a bit and see if anything comes to mind.
Modular Design
It seems like a lot of you want to build it so that modules can be easily added. That is fine, but keep in mind that some of these modules will require data to function, so we need to make sure the core system is able to support them. A good example of this would be reporting. Business owners need various reports, such as a stack rank which would display a printable list of products ordered by a sales vs view ratio etc. In this case we need to make sure the store is tracking this so that we could plug this module in and it would work. This is just an example.
Our Customers
Keep in mind this store is geared towards businesses, so we really need to cater to their needs.
Starting From Scratch
It also seems like the majority wants to start from scratch. If that is what everyone feels is best then that is what we should do, but keep in mind that there is a lot of good code in the osCommerce code base. A lot of the modules (payment/shipping etc) are already OOP and with slight modifications should work with the new store. Without compromising quality, saving time by reusing code should be a priority.
Framework
One of the objectives of this project is to minimize code bloat. As such I feel that we should either create the framework as we build the application, or carefully pick and choose what is added to the code base. I haven't done the math, but I wouldn't be surprised if there are 10-20k lines of code processed on every page request with osc. It also hammers MySQL quite a bit as well. I'll expand on the framework a bit..
- 1.Maybe we should use the pear::MDB2 package as it already supports multiple database types if I am not mistaken.
- 2.A custom database driven registry with categories for the store's configuration, many of which will be editable in the admin.
- 3.Swift Mail for the mailing system.
Payment
A store won't do a business much good if they can't get their money. The store should come with a robust set of payment modules by default. Authorize.net, Paypal, Google?, and Mail in payment for sure.
Ajax
If Ajax can be added in such a way that it would help increase the stores sales, then yes, I think we should jump on that. Otherwise I think Ajax should be used sparingly, if at all on the client side. On the admin side, Ajax may come in pretty handy.
Adding Products
Adding products should be made as simple as possible. In osc it can sometimes take 30 minutes to add one product. Anything we can do to decrease/speed up data entry for the store owner should be done. This might be a place where Ajax would be great.
PHP4?
PHP4 Support. I really don't see any reason why we shouldn't support PHP4. I know it's a lot more fun to use constructs and everything, but really there isn't a whole lot of concessions that need to be made in order to support it. I suppose we will have to discuss this further, possibly as code is being written, so that we can identify exactly what will break this application on PHP4.
Server Requirements
Minimum Server requirements should be fairly low, and the code should adapt to what is available. For example Apache, PHPX, MySQL, etc for the base. Now lets say they have GD2 installed. The store will detect this and activate automatic thumbnail generation for product images. If they don't have GD2 installed, they will need to create their own thumbnails.
XHTML/CSS
XHTML/CSS compliance. Yes it should be as standards compliant as possible. The main issue here though is to make sure the people using the store can change the layout as they please very, very easily. Not many businesses want a cookie cutter store, they want to be able to modify the layout. We really need to focus on this.
Rough Draft - System Schema
Let me attempt to break the entire system into some chunks..
Framework - Whatever we need should be added, nothing more
Products – Display, Edit, Add, Delete, Hidden, Visible
Shopping Cart – Add product, Change Quantity, Modify Quantity, Remove Product, Destroy, Transfer To Account (ie someone logs in, we can then associate the cart to their account), Display
Payment System – Very simple class which passes parameters to the chosen payment module, receives a response and handles it accordingly.
User/Customer accounts (for features such as order history) – View Orders (order status), Order History, Edit, ...
Administration – more on this later.
Ok, I think that covers most of what has been talked about.