Question for Pugdog regarding the shopping cart you have talked about:

I know you are waiting patiently for the next Links SQL release like the rest of us, and once it is released, upgrading your existing stuff will most likely take priority over new projects, but I was wondering if you think something like the following will be possible with your planned shopping cart add-on.

I am currently working on a simple shopping cart in DBMan. A few problems are that there will be categories and subcategories (not its strength) and some items need to be listed in multiple categories. Hopefully the alternate category bug will be worked out in the next release of Links SQL! Also, there will be packaged pricing options, multiple discounts, etc., all of which seem like they would benefit greatly of a database backend.

Thanks,
Dan

Hi,

Complexity is the nature of the beast <G>

Packaged discounts would best be handled by a "discount" script. For instance, once the order is generated, or items added to the cart, a "calculate any discounts" button could be clicked and the users see what they were entitled to. This would run automatically before check out.

The problem with trying to have packaged discounts run in real-time, (for lack of a better word) is that the logic becomes incredibly complex, for very little benefit. You might expect that of Amazon.com or Reel.com, but the average user would _not_ expect it from their local video store. They'd just want to know they WERE getting the discount.

But, I'll probably have a "group" function, similar to what you see in Quick Books, that will allow taking multiple items, adding them to a group, and entering the group as a single priced item.

Yes, the upgrades will take priority, only because I'm _hoping_ that the upgrades will solve a lot of the problems.

Because I'm working through the DBSQL.pm, and am using as much of links code as possible, multiple categories _will_ be enabled, but I'm again _hoping_ that there will be a major fix to the alt-categories and alt-links. FWIW I've sent Alex long tirades on the issues/problems and he's been interested and agreed that future growth will depend on some fundamental changes to the logic (ie: moving completely away from the flat-file origins to SQL/database/tables).

But, I really don't have any extra knowledge of the upcoming release, so I'm not being coy.

Thanks for the reply. I agree that the packaged discounts present the biggest problem. The way I'm approaching it right now, and quite likely would have to do so even with something like Links SQL, is to set up a separate product for a packaged discount.

For example:

Product A = $40
Product B = $35
Prodcut C = $30

Product D = package of A, B, and C for $80.

I'm thinking that even with the database empowered cart, the complexity is still a major issue, as you pointed out. I haven't thought through the logistics, but maybe a flag could be set to look to see if a combination of items were ordered, and if criteria A, B, and C are met, then the order is actually Product D.

I don't even want to think how many millions of dollars Amazon.com has likely poured into their database(s).....

Let's all hold hands and pray for a vastly improved alt-cats/alt-links!

Dan

Actually, I think McD's has the best. After taking a lot of criticism in the 80's I think their input automatically makes "extra value meals" out of the odds and ends you order to give you the best price. I could be wrong, but I think a few times in the past I was surprised at what came out.

I wonder if in order to do that you'd have to make a tree of the packaged deals, then match the order against the tree. It would be the logic of a "jumble" taking the "letters" you have and seeing if they matched any known word.

Given it's going to be awhile before we get the new version, I can't sit still any more. THe past 10 days have been torture enough.

I'm going to get started on this, and work on the central features, in stand-alone code segments, without modifications to anything but the Links SQL templates.

I have some of the code done, but I need to know what core features people would want in the cart, and how you'd like it to work with Links.

I will have a "Shopping Cart/Catalog Only" version, which Links SQL _is_ the catalog/cart, and one that hooks into the Links SQL you might be running on your site, with the addtion of a few extra table fields and some template tags.

What I would _really_ like to see, is someone working on a Book/CD/Video add on, to integrate Amazon & Barnes&Nobles & Reel.com into the program. Amazon should be fairly easy, B&N has tried to make it easy, and Reel.com I haven't a clue. This would be a separate thread, and there is plenty of room for a group project on this. THere are many aspects -- from searching, to creating targeted book links (like a spider, but for books only), etc.

But, back to the shopping cart.

I'm going to _assume_ (Felix Unger not withstanding) to figure the user-sessions features are going to be in the next version of LInks, and will be accessible to other programs. So, no user-logon, session tracking, or other features are going to worked on at this point.

Also, I'm going to make the assumption that certain user data will be entered in the primary user-logon, so a user hsa one ID/pw for the entire site.

The final assumption is that I'm not going to use cookies for anything except ID and session data. Everything else will be stored in sessions tables (this will be worked out later). I don't want any arbitrary limit on data, _AND_ most importantly, I would like an aborted session to persist to the next log-on, or for some pre-determined time. (A user would be advised a previous shopping session exists, and they can either resume, or start a new one.) (remember, if everything is ID/PW coded, "session data" is only necessry for time-tracking and current "state" information, everything else is stored as a "session record" in the "Sessions" table). This can lead to "wish lists" and persistant carts, since does anyone really want to lose ANY sale??

The "User_extra" table will contain data for those users who chose to purchase from thes ite -- such as full address, billing, shipping, and credit card or other payment info. This table is not set, will be linked by the UserID to the rest of the site, and can have extra fields added to it, as long as certain "required" ones are left alone.

The "Transaction" table will contain the UserID, order_num and a few other fields necessary for order tracking.

The "Ordered_Items" will be linked to the "Transaction" table via the order_num
and will contain the line-items for each item ordered. They will be linked to the Transactions table via the order_num (to use the UserID would violate rules of 'normalizing' but might add extra functionality, so I'm not sure).

The "Ordered_Items" will contain the Item_Num and extra fields to override any of the information in the "Item" record. Why? Let's say you want to apply discounts, sale prices, etc to _some_ people -- (perhaps a members discount on an item). You can enter this, and the PROGRAM code can set the price in the Transaction record, without having to affect the "Item" record at all. If there are no override pricings then the "default" data is entered in the fields. (Why? Lets say you change the prices of the Item in the database. Some programs might force you to enter a new Item number for that in order to allow proper recording of old transactions. If this information is recorded in the record, then the "Item" table can change, without any effects.) (If you change the description or anything else that isn't tracked, you will be presented with an option to enter a new Item_Num or keep the old one, with a warning that previously entered orders may become inaccurate.). This seems to be the best way to handle this, but I'm open.

I haven't worked out the override system, but it seems to me the best would be to use a system of something like Item_ID/Key_to_apply_Discount/discount. That way, when someone orders an item, the PROGRAM checks the "overrides" table, and sees if that Item &/or User is eligible for any discounts. (This is for a LINE-ITEM discount. Any "group" discounts are applied at the end -- such as 10% off for being a "Member".) This is for "special" discounts, sale prices, etc. Each override would have a UNIQUE number, and (you could copy them, if you wanted to change it but) every time you changed the override (or sale price, or discount, etc) you had to create a new override record. This would allow multiple overrides, expirations, etc, and allow you to change an override at any time. Obviously, each override would have a date_start and date_stop. (For performance reasons, expired overrides, deleted items, etc would be moved to "expired" tables, for secondary look up if necessary. The "purge" features of this have not been worked out yet, but the catalog has to be working and running before anything needs to be purged, so I guess I have time <G>)

Then there is the "Item" table, which is the equivalent of the "Links" table, and a "Categories" table, that is the same as the "Categories".

I'll try to allow internal alt-link and alt-categories at a later time, but this version is not going to have that.


This covers most of the "variable" tables. I'd like to know what sort of data you want to be tracked in these tables, since some of it can be made part of the defaults, other parts you'll have to modify on your own.

There will be other tables, hopefully from 3rd party sources, to keep updated on shipping, tax, and other rates. I'm looking for sources now. Nothing is set. I'm _not_ going to try to make this some super impressive stand-alone program, but a basic functional program to solve a specific problem for "average" websites.

I'm working from my own needs of a way to set up one-of-a-kind and inventory items, in an easy to use and integrate way. Template based, automatically generated. Order handling -- MC/Visa/etc. USPS and UPS or FedEx. I'm not going to try to support everyone, or everything. I can't, and I have no delusions of trying :)

If anyone has good open-source products they've found for any parts of this, please let me know. I know there are transaction gateways and modules being worked on, and I will wait for those to get developed. You still need to have your own merchant accounts, etc. But this program will _HOPEFULLY_ be able to pass the data to any of them that you want to. If your ISP offers transaction processing, hopefully it will be an easy mod to send the order data to them for processing, and get it back (getting it back depends on them, more than anything else, sending it can be faked in any number of ways.).

Anyway, this is the start.

(I'm not working on the banner or other systems that are going to be in any way part of the new Links SQL. Once it's released, I'll be happy to hack on them :))

Oh... the final word. YES - this probably could be done in PHP, and maybe even more easily and with a lower overhead than perl, since it's 99% database look up. The _problem_ is that you'd have to develop a new set of templates and template parser to allow the "look and feel" of your main site to be carried through the catalog. By using PERL and DBSQL.pm, and HTML_Templates.pm, etc, the look & feel is maintained very easily. You also couldn't have built-in automatic maintennance features (cron). Additionally, the new release of LinkSQL promises cross-product integration that allows whole-site development with one set of logic for email, spider, links, and whatever else is in the works. I'd rather stick with that. If anyone wants to develop a PHP version that works with this version, feel free. I'm going to stick with perl at least for now.



http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/

Whats the problem with a cart?
Take any script around that needs a form and set all needed values as fields in links, build a link.html or cat.html with the form around and link to the cartscript, thats it, not more not less.
Robert

There's more to it than that. None of the open source shopping carts are set up to deal with unique items, first of all, and they all have major limitations in other ways. Minivend -- many people can't get to run.

Modifying the Links scripts using the same template and database engine is the best idea, and I was able to get a basic shopping catalog/order system working in a couple of days. It's now a matter of generalizing and adding in features.


http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/

Also, let's define terms.

A "shopping cart" in it's original -- and basic -- concept is little more than a means of taking items, quantities and prices and presenting the user with an invoice they can pay.

There are many shopping cart scripts. A <FORM> can be a shopping cart.

The real power of a "shopping cart" lies in the software used to present the items for sale to the customer -- not in holding those items.

When I use the term "shopping cart" I'm really referring to a well featured shopping/catalog/cart system that allows searches, catgories, organization, maintennance, and checkout. Other features are wish-lists, on-hold, and "registry" items.

When you go to the store, the shopping cart is nothing more than a basket on wheels. You don't usually pick your stores by how nice their baskets are. You usually pick your stores based on what you are needing to buy, and which stores are best to use.

From my development point of view, I have about 5,000 unique items, and 500+ "stock" items that I want to put into a catalog. Hopefully, I'll have at least a 10% monthly rotation on the unique items. I need a system that is capable of handling that. That's what I'm designing, since no one else out there has one.


But, the system should be as capable of handling 10 items, as it is 10,000.




http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/

Sorry, i will stay at my opinion.
Divide the two things.
Use Links as a database for your products (you must do some logical things to have fields and values for all products you would like to serve)
Then you need another tool that just do one thing:
Take the data via form and save it to a database, let user delete, modify and BUY.
I use a simple script from elitehost.com; this has the additional advantage to be an affiliate-programm, too.
(249$) pure perl and easy to change.

Unfortunately this cart runs in a closed area, so i cant show it to you.

I think its to much thing too change links to do the shopping too; you need tables for the seller, tables for the buyers and a lot of stuff more; i will send my links.html to show what i mean and how easy it is: