Help Rebuild OsCommerce

Looking for volunteers to join your project? Need help with a script but can't afford to pay? Want to offer your services as a volunteer to build up your portfolio? This is the place for you...

Moderator: General Moderators

User avatar
Luke
The Ninja Space Mod
Posts: 6424
Joined: Fri Aug 05, 2005 1:53 pm
Location: Paradise, CA

Post by Luke »

onion2k wrote:1. PHP 5 will limit the install base considerably. Most hosting companies are still running 4.3, and will be for a while yet. If the idea is to learn a lot from writing a big application then PHP 5 is the way to go. If the idea is to replace OSCommerce you should stick to PHP 4.3. Or, better yet, write code that works with both.
I would prefer to write this application entirely with PHP5. I'm pretty sure that this application (even with a few of us working on it) is going to take quite a while to complete... because we all have other priorities. I honestly believe by the time the application gets to any sort of stable release point, the PHP5 install base will be quite a bit larger. Even with that aside, I still vote PHP5 for the second reason you posted.
onion2k wrote:2. Objects are a good idea because they'll let you organise and encapsulate the code neatly. Other than that there's no difference between object oriented and procedural code.
Agreed. OOP will be much easier to maintain in my opinion. Actually... Were this project to go the procedural route, I would not want to be a part of it. Simply because this is a learning experience as much as anything.
onion2k wrote:3. Why would a shop need Ajax? Or is that something you want to use for the sake of it?
Ajax should have nothing to do with the core application...

With all this talk about PHP4, PHP5, AJAX, etc. I think that we need to define a few things... first of all the scope of the application: What exactly is the focused goal of our application?
Second: What are the minimum server requirements we will expect to run our core application?

Since one of the original ideas that sparked this application was XHTML and CSS compliance, I think those are already in the box.
User avatar
Oren
DevNet Resident
Posts: 1640
Joined: Fri Apr 07, 2006 5:13 am
Location: Israel

Post by Oren »

PHP 5 and OOP all the way, otherwise, I'm not going to take any part in this project.
The Ninja Space Goat wrote:I would prefer to write this application entirely with PHP5. I'm pretty sure that this application (even with a few of us working on it) is going to take quite a while to complete... because we all have other priorities. I honestly believe by the time the application gets to any sort of stable release point, the PHP5 install base will be quite a bit larger. Even with that aside, I still vote PHP5 for the second reason you posted.
Exactly :D

I'm still not sure about the payment part, we need some security pro. for that part... I mean a real pro.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

Let's not dwell on the payment module(s) too much - let's get atleast a framework done so we can begin, then when the payment module comes around we can cross that bridge when we get there.

So, in order of events:
  • Decide upon/create a framework and library, and conventions.*

    Create list of 'core' functionality, segregating anything that is not absolutely fundamental to the running of the application.

    Design and normalise table structures for said core functionality.

    Draft pages with basic navigation - even if it's static HTML and ugly, for the meanwhile.

    Begin sculpting code.
It's safe to say MVC is a given, but what does everyone think about TDD (Test Driven Design?) being applied as well?

*For documenting I propose phpDocumentor or DoxyGen. Naming I am not fussed but I do think we should all agree on a one naming convention so we don't have some classes called This_Is_A_Class and others called ThisIsAClass or some such.
sike
Forum Commoner
Posts: 84
Joined: Wed Aug 02, 2006 8:33 am

Post by sike »

hi,
Jenk wrote: Decide upon/create a framework and library, and conventions.*
the framework will emerge while designing the application if you follow the oop paradigm. there is no need to build a framwork upfront imho (set aside that writing a framework is a full blown project on its own)
Jenk wrote: Create list of 'core' functionality, segregating anything that is not absolutely fundamental to the running of the application.
did you mean slaping together some use cases and specifications?

Jenk wrote: Design and normalise table structures for said core functionality.
personally i tend to do the database stuff as late as possible. it's more about developing a domain language using objects. the db is a bit more of a persistent store for me.
Jenk wrote: It's safe to say MVC is a given,
you could be right here but chances are that there will evolve a better way while doing this project (:
Jenk wrote: but what does everyone think about TDD (Test Driven Design?) being applied as well?
i would say : definitely yes. untestable code becomes a true nightmare as its getting bigger and bigger. the other side of tdd is that it leads to clearer encapsulation and responsibilites. it guides you to write cleaner code imho. as a sideeffect the tests form somewhat of a documentation.


cheers
Chris
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Post by onion2k »

sike wrote:personally i tend to do the database stuff as late as possible. it's more about developing a domain language using objects. the db is a bit more of a persistent store for me.
Interesting approach. I do the opposite. In my opinion an application is just a system for manipulating data, so the database is actually the most important aspect and always gets designed first.
sike
Forum Commoner
Posts: 84
Joined: Wed Aug 02, 2006 8:33 am

Post by sike »

onion2k wrote:
sike wrote:personally i tend to do the database stuff as late as possible. it's more about developing a domain language using objects. the db is a bit more of a persistent store for me.
Interesting approach. I do the opposite. In my opinion an application is just a system for manipulating data, so the database is actually the most important aspect and always gets designed first.
that's what i did in the past (: but you have to be carefull that data models don't drive object models (and vice versa)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

re: MVC, definitely right that a more suitable process will evolve, but MVC will be the primary role, at least until we kick off.
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Post by onion2k »

Why do you? Because that bloke says so? I disagree with him.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

EDIT: Can we save this for another thread please? :)
User avatar
Benjamin
Site Administrator
Posts: 6935
Joined: Sun May 19, 2002 10:24 pm

Post by Benjamin »

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.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

I believe you are thinking too far ahead astions :)

We all know we will need a payments system, but we do not need to prevent anything being built until we have solved that problem, we can construct atleast something that resembles a catalog and come back to the payment problem if need be. We also should chose one payment method and stick to it until we have a system constructed, we can then add extra payment methods as extra modules after. This will be the final stage of testing before release - testing if our modularity works :)

PHP4 hmmm no, I'd really rather we didn't. The other thing to realise here is it's likely PHP6 will be out long before we are at any stage where we can release this shop software.. it's a project that most, if not all involved can only do in their spare time and thus it will take a while to produce. :)
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Post by onion2k »

Jenk wrote:We all know we will need a payments system, but we do not need to prevent anything being built until we have solved that problem
I don't think anyone is suggesting preventing writing code until the payment system is worked out, but you really shouldn't start coding anything until you know precisely what data you're going to be maintaining in the system .. and what inputs various payment services require will influence that. It'd be daft to get to the end of the system and only then realise that an EPDQ payment plugin requires an SKU code for each product and you've not got one.

If you do a very complete analysis of the data requirements you should be able to handle any payment gateway out there, but if you jump straight into the code you will miss something .. and however awesome your code is, adding key features later will result in hacks. It always does.

Start by planning and specifing whats needed. Don't just start writing code.
User avatar
Oren
DevNet Resident
Posts: 1640
Joined: Fri Apr 07, 2006 5:13 am
Location: Israel

Post by Oren »

PHP 5 only. We really need to encourage web hosts to move to PHP 5.
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

I'd suggest writing the specification for the project as detailed as possible (terms from my world are design document and technical design document) including delivery schedules, complete feature list, a work breakdown structure -- the whole gamut -- before much is written in code. Build the unit tests for that feature list, then start building the code. The nice part about taking the time to write out all this documentation is if anyone leaves the project, someone coming in has something to reference to continue from.

These documents aren't static by any means, they will generally be altered at least once a week.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

Which begs the question.. who is going to volunteer for that? :P

EDIT: or rather, who is going to volunteer to be the doc monkey? :lol:
Post Reply