| SitePoint Sponsor |
I can only assume you are nuts for keeping people from developing their skills and expanding their knowlegdeOriginally Posted by NikLP
. Creating this kind of things really helps you develop your skills and give you a lot more knowlegde of the way scripts and websites are build.
On the other hand, if invision2 has a small timeframe to build it in. You may be right and using a equivalent is the best way to go.
It's a fairly small timeframe, but I don't think it's beyond me.
I've got it all planned out so hoping to start shortly.
how to implement has 100000000 ways but you'll still be faced with 1 question.
Session vs Database
I would side with database only because most shopping carts work this way (like amazon)
That is a good point but if the company's making millions of revenue per year, those open source is not efficient. Look at amazon, do you think they used open source? I think not.
whooo! this is tough, Ive been re editing my shopping cart, and I still cant get it right
Keep the option of storing products for CUSTOMERS who are registered on the site. This way, you can monitor the products they were browsing in a database and query accordingly when customer returns. (And logs in)
If the customer is not a registered user, I'd say a 24 session lifespan should be max.
As someone previously mentioned before, Amazon follows a similar pattern. But someone who is registered is easy to monitor and thus develop browsing pattern algorithmns to cater for customer taste.
Hope it works out.
Regards,
MC
Innovative Design and Development Services
Design: XHTML - CSS - Photoshop CS - Flash 7 - Illustrator
Development: Java - JavaScript - PHP - MySQL - .NET - Struts 2
Order ID
hehe
I don't write databasey thingies but I'm going to butt in here as a customer:
If you are going to rely on cookies for anything, TELL ME. I the user need to be told that your site requires cookies and that I need to Turn Them On (or, in my specific case, if they need to be stored longer than x time, I think I have my browsers all set to destroy them when browser closes or after 7 days, depending on browser).
++ to joebert for login-password. I don't want ANYONE other than me getting into my account, esp if it's like Amazon where they already have my payment info, card number, shopping cart.
The login-password setup doesn't come into play until I've bought something and become a customer.
If the user closes his/her browser and have not actually done anything (clicking anything that's any sort of POST submit) then nothing should be saved. I'm not sure who in the user world assumes a browser will remember anything after it's been closed, unless they are using Opera or Firefox's Quit-n-Save setup. If they want to save something they need to select something, add something to the cart, go to payment, DO something.
Otherwise, if I go to the hospital to visit someone and decide to do an order on your site (without login-password) on their public computers in the lobby, and you made some temp id for me that stays in some week-long session without login-password, then you've just given every user of that machine the option to see my account or stuff I've done for the next week (or at the very least, the forms will still be filled in with whatever I'd set in them). Not every computer is private.
In that vein you could do what one of my Evil Banks do: they ask if the machine you're on is public or private and I assume they do different things when you say "Private". I always say "public" so it doesn't remember stuff for me.
With our insurance sites, there's a session of at least 24 hours but not if they've actually finished and asked for a policy. We're using a session to hold in any temp-stuff that's not yet been sent to the permanent database (as they are not yet a customer), and a token to clear that when they've become a customer (bought a policy). No matter who goes back on that browser, everything's wiped. Forms are empty. If they need to change something on a policy they've already bought, we need them on the phone or in person anyway (eventually we will also set up a login-password option too but that's in the future).
Ok, well post your IP address so everyone writing a web app can do an IP check and display a big ugly box saying something in regards to cookies if the IP is a match. I assume you said that so if something doesn't work for a user, they can't blame the website for not telling them about cookies being required.
However, most users don't know what cookies are, and so the extra clutter/text on the login screen may only confuse the user and possibly disrupt the flow of the interface. What I do instead, is send a cookie to the browser when the user loads the logon screen (if there's a logon box on every page, then set this cookie on every page unless it already exists). After the user submits the login form, if the cookie exists, you know the user has cookies enabled. If the cookie doesn't exist, you know that cookies are disabled and you warn the user of potential issues they may experience as a result.
I'm not absolutely sure how you plan to have your shopping cart work. There's basically do possibilities here...
1) You have a product (with a unique id). When a user adds that product to their cart, they can select exactly what type they would like (colour, tyre type, etc).
2) You have a range of base products. Users can then customise many aspects of each product when adding the item to their cart (essentially creating their own unique product).
Which of those two are you trying to achieve? And will the final price vary depending on what attributes or customisations the user selects? If that's a bit confusing, maybe just tell me if this is kind of what you had in mind...
http://www.coffeeworks.com.au/view_p...p?product_id=1
That's an online store I made a while ago.
Last edited by Wardrop; Feb 25, 2009 at 23:02.
No i don't agree with you .... its not possible to keep session timeout longer than a week....
Sounds good, as that DOES tell me hey, you need cookies enabled! That the message only appears for users who seem to not have them enabled is fine-- sounds like the way to do it.
I may not be at my own machine when visiting a site. When something doesn't work, I don't know why-- is it because of some security level set on the browser I'm using, or a firewall acting goofy, or what?
My banks usually telll me I need either cookies, or Javacript, or whatever enabled. It's courteous to tell your customers what they need to have so that they don't waste time banging their heads against the keyboard before leaving in frustration. I'll take less frustration over "design" any day. And when it comes to buying stuff, rather than surfing, I'll bet I'm in the majority.
*edit since I saw this Apple claim, I think I should repeat it here:
I dunno if they're really the first, but they're not going to be the only one doing it. Whether users know what cookies are or not, it's important that they know your site relies on them if they have them off (which you said you already do, Wardrop, so this isn't an answer to you, just generally thrown out into the thread).
Last edited by Stomme poes; Feb 26, 2009 at 03:43. Reason: added saffy talk
I don't know why you'd use third party systems to achieve this. Better build it yourself, have the satisfaction that you've done it and also have piece of mind that you know how to develop/maintain it in the future. Anyways it would probably take as long to write it from scratch as working out howa third party system works.
As far as how to do this i'd go down the rout the jimm 023 suggested but put an extra condition in there. This would be if the user is logged in to their account then there's no need to bother with cookies....utilise their userid....persoanlly i've always gone down the route of if a user puts something in their cart and is not logged in then refer them to a log in page where they can log in or register and when they're done refer them back to the original item page. Perhaps my way is not as intuitive as allowing even unregistered users to add items to carts?
You can post your project at freelancerplace . com
If you have to ask this sort of question, I'd question why you're building a website from scratch instead of using one out there. Unless it's for educational purposes I guess.
Do you want this to be a strictly web based application or do you want the users to download something onto their computers and then connect to your cart using that downloaded application rather than using browser ?
Chris, Programmer/Developer, Chrisranjana.com
Chennai, Tamil Nadu, India.
Software Company. Php Web developers
I just wrote a cart, not a "shopping" cart but a "quote cart." The site visitor fills the cart with two or there products and enters a bunch of info about his requirements. When ready, he submits the cart to the website owner who uses it as a worksheet to prepare the quote and the cart then emails the quote to the customer.
To answer your question:
- The cart is saved to a database
- The client browser has a cookie valid for 30 days
- The cookie has the cart ID which is how the client is connected to his cart, no registration required. The downside is that it only works with one browser.
- A Cron-Jobs deletes carts that have not been worked on in 32 days. By then the cookie should have died.
I'm hoping to go live next week. I hope that helps.
Denny Schlesinger
web services
Posting Permissions
Bookmarks