Welcome to WebmasterWorld Guest from 184.108.40.206
Forum Moderators: buckworks
I'm just looking at the osCommerce database model to help me create my own and I'm wondering how the delivery address details work.....
I will have the cardholders address permanently stored in the Customers table. But the Customers table does not store the delivery address as that is subject to change on each order....
Looking at the osCommerce model they have the delivery address and credit card details stored in the Orders table, which is fine. But I'm also assuming that nothing enters the Orders table until the order is officially submitted. Is this correct? If so, how does the user check the order before submitting? Its usual for the user to input all the details and click a proceed button which will direct them to the summary of an order (products, prices, credit card details, cardholder address, delivery address etc). The customer will then check everything and submit, right?.....
So, if none of the order details have entered the Orders table prior to the order confirmation then how is the order summary displayed on screen? Or do the details enter the Orders table but are deleted if the order is not confirmed?
An explanation would be very much appreciated. Many thanks :)
Is this correct? If so, how does the user check the order before submitting?
That is correct. The variables for the order are by using a session. When the times comes for check out the customer is given one last chance to review their order after the shipping info has been submitted. Once the form is submitted, the credit card is checked and charged, and the order is completed.
I understand your fear. It's a bit scary but rest assured it works well. There are MANY installations os osCommerce out there. Bare in mind many of those have undergone some significant customizations but - nonetheless - they started as osComm and still have some osComm in them.
re: CC# in a session Yes. Is it encrypted? I don't think so. Session vars are safe - in general - unless they're hijacked by someone. That's unlikely but possible I suppose.
Now imagine things don't quite work like you'd expect them to. Suppose for some unknown reason, halfway through the process of entering an order, Apache or the database crashes, you lose a connection, power, are unable to send confirmation emails, whatever.
Going through that checkout code, there is no point at which it would seem benign to have an error. Because the underlying db is MySQL this was in use without transactions. If you are using the inventory tracking, an order could be placed and inventory not substracted. With transactions, it's all or nothing -either everything works or you don't do a thing, so there's no corrupt data to deal with.
There are a lot of other similar issues that just scare me. The fact that the code does not enforce a good separation of concerns make it difficult to maintain (there's HTML and SQL in the same file!). Although they mention in their "development workboard" that they plan to make more use of objects, you can see that milestone 3 has been almost a year in the making. This suggests to me that maintenance is slow, likely because of the state of the codebase.
Though I guess that's all a bit off topic :(
If I properly understtod you, BigHit, the explanation is:
1) User have to log into his account prior to checkout.
2) If user does not an account prior to login, he has to create an account and give at least one address.
3) That address is then stored in 'address_book' table, and then 'address_book_id' entry value from 'address_book' table is stored as 'customers_default_address_id' in 'customers' table.
4) During checkout process, the entry number 'customers_default_address_id' is read from 'address_book' table and offered as a default delivery/payment address.
How CC data is processed depends on actual payment method module -- it can either be stored in session variables, or CGI variables.
After user has commited an order, all the data is written into 'orders' table -- as real data, not as a reference to an another table.
One last thing which I'm unsure about.....
Initially I'm going to have 1 Product table and 1 ProductOptions table which will contain all the different variations of a product and somply looks like this:
optionID - PK
productID - FK
So, at the moment, in my ShoppingCart table I have this:
cartID - PK
productID - FK and PK
optionID - FK
customerID - FK
I'm pretty sure that won't work though because if a customer adds a bike with the option Small/Red and then adds the same bike with the option Medium/Red, its going to increment the value, yes?
So do I need to incorporate the optionID into the ShoppingCart primary key and not have the cartID as part of the primary key? Or do I need to do something different with my options table? Or any other table for that matter?
Sorry for all the questions, I just need to be very comfortable with this rather than rush into it.
Many thanks :)
And cart something like:
cartID - PK
productID - FK
optionID - FK
customerID - FK
I think you can have cartID as PK, and all other as FK.
If you add something to cart, cartID will increment automatically.
Just check if customer adds same product with same option one more time to cart, and increase quantity rather than add one more product.
I'm strongly leaning towards releasing my cart under a GPL license. It's nowhere near as feature-packed as OSC, and it still needs better architecture. BigHit- any chance you'll release your code? :)
Morgenhund: The book "Design Patterns" and the documentation for Struts is what I used, along with various articles. If I had to start over, I might begin with the book "Web Application Architecture: Principles, Protocols and Practices"; you might want to look at some of Sun's sample applications. Can anyone else suggest a good resource?
That said, at minimum a good application would cleanly separate data, logic and presentation. A designer should be able to modify any aspect of the appearance of a site without ever touching anything dealing with application logic or SQL. And a programmer should not have to deal with HTML when a designer does that job. All of that is impossible with OSCommerce :(
Well, I don't actually think it would be of much use to anyone as it will be my first attempt at my own E-commerce solution. Plus I've only had a couple of months of good experience with .NET. Prior to that I hadn't done any web programming :( I'll see how it goes, but I'm learning most of it as I go along.
Personally, I prefer to do the design as well :) I enjoy playing about with CSS and so I can completely separate presentation from content.
Ultimately, the target was simple:
A Brick & Mortar store was loosing their site and needed a new one within 2 months. Previously they had an e-com section, but all items in it were part of the host's setup.
So, a re-design, a quick & dirty site, then a full-blown one. But still, no merchant account, and probably no orders... but just to have the feature there. And more accurately, the physical inventory that they currently had be browsable. Of course, it did have to be secured.
Also, shared hosting, not dedicated. Dangerous, but there are simple ways arround those dangers. :~) But the most demanding thing was not to have the main inventory online, but rather in a program called BookManager (FYI, bookmanager is a DOS power-user program, with all content aimed at power-users, and worst of all, closed source - the only way to extract the db was with CSV, unless I wanted to dabble in reverse-engineering *shudder @ DMCA*). Updated (over writen) online weekly though.
Anyways, everything ran under a Class header with title's like BOOK-FICTION. (and yes, EVERYTHING WAS IN UPPERCASE AND THERE WAS NO WAY TO DO AN INTELLIGENT CAPITALIZATION. Also, lots of stuff was abbrviatd).
So, trying to think of a package to meet these specs drew me a blank, so I started from scratch.
... Item Groups and Bookshelves. A bookshelf is defined as an object capable of holding Item Groups, Individual Items, or other Bookshelves.
... General info, members, past orders, etc.
... Holds Credit card info. Database info encrypted, and no access passwords stored... anywhere. :~)
Anyways, the amazing thing is I did it all. Took about 4 months, mixed in with study time, and learning PHP. I know, I suck. A good coder could do it in, what? three weeks?
Used Java to convert/filter/... the CSV file into an SQL file. (Which I shall make Free, as in beer).
Anyways, I got $2g for it, not that great, but hey when working under parents, you usually get nothing. And I got to keep the rights. Anyways, rewriting it to make use of some database classes I wrote (I don't like the other's I've seen), and ultimately cut out all global functions. If anyone thinks it should be Free (maybe not beer this time), I probably will make it so. Or maybe I'll put it on a digital shelf for a rainy grave.