Shopping cart framework
Moderator: General Moderators
Re: Shopping cart framework
I guess the only come back I have is that its under BSD licensing, so anyone may branch the project if they don't like the way I run it... You will always own the rights to your own code, if you choose to contribute to the project then you just licensing it to me. Although I do have control over the google SVN account & domain name, I think the project should be community owned. The thread could easily reach 10 pages before we decided on a name, so I'm just trying to cut to the chase so we can start writing code. "Google" doesn't really tell you anything about what they do, neither does "yahoo", neither does "joomla", or "magento". I think "metator" is an ok name.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Shopping cart framework
The name and license sounds fine to me. Not sure what the issue is. The biggest problem is getting something useful actually built. 99% of projects fail. That's mainly because groups have a hard time staying focused on what is actually important and adds value.
(#10850)
Re: Shopping cart framework
Well I put down something basic, took only a few days of work (despite the fact so much time has passed). Its all unit tested, there's no admin interface, its just open to all users for right now. You can add a category from the category page (give it a title). Then you can goto the products page and add a product, choosing the category, and set a title & price for that product. Very very basic but its all being done according to best practices.
http://metator.com/
http://demo.metator.com/
I added Christopher with commit access. If anyone else would like to help out let me know (but keep in mind unit tests are required, not optional)
Next up I want to do "configurable" products (just input their info, and persist them for now). Trying to think of the best architecture. Some users hate having to first create "simple products" and then create a "configurable product" and link them, it creates a mess with any substantial sized catalog and consumes time.
First I'll probably add import/export support for this simple product (see below, update this is done), according to the project roadmap I wrote a few months ago, then I'll try think of a good import/export format for configurable products. Thinking ahead though I think I'll use something like wordpress, there is a "posts" table and as you compose a post it also saves "drafts" in the same table. I think I will recyle that idea but for "products & product options". There will be a "product option" class that re-uses the "product" class & database table. From the user's point of view, they will simply:
1- click create product
2 - type t-shirt
3 - under "options" add "color" as an option and values red/blue with prices bound to each value.
4 - they will press save and this t-shirt will show as 1 product. Some other screen will let them browse "product options". This is a big complaint of other systems, having to see "red shirt XL", "blue shirt XL", "red shirt small", "blue shirt small"... what a mess. I think that should be possible but not mandatory and certainly not the default behavior. Also they should be able to create those products from one screen, in 1 click, and easily hide/show the "options" when reviewing their products.
I also have a cool Zend Form / javascript form element I wrote. Instead of having to do the categories and products on separate screens they can add a new category from the same page. Next to the category drop down would be a link that says 'new'. When they click it would be a javascript thing. I'll let you know when I get that part up & running, I'm going to put javascript validation on all the forms (but as of right now theres no validation rules yet..)
update this is done, you can now import product's titles, price & category. Regarding whether to use category IDs or category titles I implemented both, it detects which you are using. You must first have a category created, you can then refer to it by ID or by title and it detects it while importing products. When importing, columns can be in any order. A future feature could be to auto-create the category if one does not exist, but that is feature creep at this early stage so I won't go that far yet. Next up is how to do configurable products, aka a 'complex' price object that has a dynamic value. Perhaps a good way to do this would be to have a separate methods... for example PriceAsLowAs() PriceAsHighAs() and PriceAsConfigured()
http://metator.com/
http://demo.metator.com/
I added Christopher with commit access. If anyone else would like to help out let me know (but keep in mind unit tests are required, not optional)
Next up I want to do "configurable" products (just input their info, and persist them for now). Trying to think of the best architecture. Some users hate having to first create "simple products" and then create a "configurable product" and link them, it creates a mess with any substantial sized catalog and consumes time.
First I'll probably add import/export support for this simple product (see below, update this is done), according to the project roadmap I wrote a few months ago, then I'll try think of a good import/export format for configurable products. Thinking ahead though I think I'll use something like wordpress, there is a "posts" table and as you compose a post it also saves "drafts" in the same table. I think I will recyle that idea but for "products & product options". There will be a "product option" class that re-uses the "product" class & database table. From the user's point of view, they will simply:
1- click create product
2 - type t-shirt
3 - under "options" add "color" as an option and values red/blue with prices bound to each value.
4 - they will press save and this t-shirt will show as 1 product. Some other screen will let them browse "product options". This is a big complaint of other systems, having to see "red shirt XL", "blue shirt XL", "red shirt small", "blue shirt small"... what a mess. I think that should be possible but not mandatory and certainly not the default behavior. Also they should be able to create those products from one screen, in 1 click, and easily hide/show the "options" when reviewing their products.
I also have a cool Zend Form / javascript form element I wrote. Instead of having to do the categories and products on separate screens they can add a new category from the same page. Next to the category drop down would be a link that says 'new'. When they click it would be a javascript thing. I'll let you know when I get that part up & running, I'm going to put javascript validation on all the forms (but as of right now theres no validation rules yet..)
update this is done, you can now import product's titles, price & category. Regarding whether to use category IDs or category titles I implemented both, it detects which you are using. You must first have a category created, you can then refer to it by ID or by title and it detects it while importing products. When importing, columns can be in any order. A future feature could be to auto-create the category if one does not exist, but that is feature creep at this early stage so I won't go that far yet. Next up is how to do configurable products, aka a 'complex' price object that has a dynamic value. Perhaps a good way to do this would be to have a separate methods... for example PriceAsLowAs() PriceAsHighAs() and PriceAsConfigured()
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Shopping cart framework
Thanks for the commit access. I will try to contribute as I think this is an interesting and worthwhile project.
So I started reading and got to your basic and "configurable" products. I needed to look back to find what you were talking about and found this is a previous post:
). One thought: I have sometimes made these Master Products as a special case of a product while other times made them a special case of a Category. Perhaps the latter would lead to a clearer conceptual solution, but it does have a problem or two as I recall.
I would like to note separately that using SKUs, while not natural for all my clients, are a best practice that leads things in the right direction always.
I obviously need to get this software up and running on my development machine and poke around in the code for a while before I can even start contributing. Having some problems getting everything checked out ... and maybe some things are missing is the repository that you have in your include path -- DataShuffler being one. At 50Mb+ the project is impressive even when not working!
So I started reading and got to your basic and "configurable" products. I needed to look back to find what you were talking about and found this is a previous post:
I have often created this Master Product and SKU distinction. My preference would be to find an elegant solution where there was not such distinction. Instead you just kept adding features as needed with Master Products being a natural extension (due to our brilliant designjosh wrote:For example Magento has a "simple product" and a "configurable product". Any product can have "custom options" regardless of it's type, so you could add a "custom option" called "color" with values 'red','blue'. It can be marked as a required field or not, they can pick different form field types (text box, vs select). On the other hand a configurable product is like having custom options, but instead of having the string 'red' you essentially have a simple product created for "red" and another simple product for "blue", then a third "master product" kind of encapsulates the two.
I would like to note separately that using SKUs, while not natural for all my clients, are a best practice that leads things in the right direction always.
I obviously need to get this software up and running on my development machine and poke around in the code for a while before I can even start contributing. Having some problems getting everything checked out ... and maybe some things are missing is the repository that you have in your include path -- DataShuffler being one. At 50Mb+ the project is impressive even when not working!
(#10850)
Re: Shopping cart framework
Regarding the dependency issue, try a checkout now. Sorry about that. My server crashed earlier so I was having trouble updating just now as well. I exported the files and checked them back in, instead of using the SVN external
I also updated the demo site, added a little subtle styling and improved the user navigation a bit. From a user perspective what would be a good way to import the configurable options in your opinion Christopher? We'd almost need a little "scripting language"
"red = price add 1; blue=price set to 5"
Of course there would be a GUI, but we'd need to serialize to something, and theres a value to making it human editable.
PS > to setup the database make sure you read the project wiki on google code.
PS > Regarding 50MB of files, Someone posted a script in code critique that pruned un-needed Zend files, we could run that as part of our build, since the unit tests invoke every line of code in theory, it should work to make sure we're including only the needed Zend files. We could also strip comments, includes, and requires... and concat the Zend files into one big file. That would increase performance and reduce file size even more.
I also updated the demo site, added a little subtle styling and improved the user navigation a bit. From a user perspective what would be a good way to import the configurable options in your opinion Christopher? We'd almost need a little "scripting language"
"red = price add 1; blue=price set to 5"
Of course there would be a GUI, but we'd need to serialize to something, and theres a value to making it human editable.
PS > to setup the database make sure you read the project wiki on google code.
PS > Regarding 50MB of files, Someone posted a script in code critique that pruned un-needed Zend files, we could run that as part of our build, since the unit tests invoke every line of code in theory, it should work to make sure we're including only the needed Zend files. We could also strip comments, includes, and requires... and concat the Zend files into one big file. That would increase performance and reduce file size even more.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Shopping cart framework
Sort of works now. I don't usually turn on short tags so all I see is partial('header.phtml')?> layout()->content?>josh wrote:Regarding the dependency issue, try a checkout now. Sorry about that. My server crashed earlier so I was having trouble updating just now as well. I exported the files and checked them back in, instead of using the SVN external
I need to understand more about the system. Is there a spec of the operations you want to support? Did you seem my comment about Product vs Category information?josh wrote:I also updated the demo site, added a little subtle styling and improved the user navigation a bit. From a user perspective what would be a good way to import the configurable options in your opinion Christopher? We'd almost need a little "scripting language"
"red = price add 1; blue=price set to 5"
Of course there would be a GUI, but we'd need to serialize to something, and theres a value to making it human editable.
And yes, it does need to be human readable. Creating a simple DSL to allow user to express common things simply and clearly would be good. I find clients often prefer something they can put into a spreadsheet and upload -- even if they have to learn the ins-and-outs of the syntax. So something like you show above might work.
Yes, it just seemed huge because I thought you were starting from more of a blank slate. We can worry about what is in a release if we ever get to that point.josh wrote:PS > to setup the database make sure you read the project wiki on google code.
PS > Regarding 50MB of files, Someone posted a script in code critique that pruned un-needed Zend files, we could run that as part of our build, since the unit tests invoke every line of code in theory, it should work to make sure we're including only the needed Zend files. We could also strip comments, includes, and requires... and concat the Zend files into one big file. That would increase performance and reduce file size even more.
At one point I had asked if this software was going to be a little framework independent. By that I guess I mean more Model focused and less Controller/View customizations. If not, perhaps we can create a two tier system with a semi-framework-independent Model layer that has all the core functionality and a demonstration application using Zend?
(#10850)
Re: Shopping cart framework
I recommend turning on short tags. There is a zend way to work around them being off, I can't be bothered to research it at the moment (this is an area of much holy war so I'll be flexible if you have a differing opinion, but for now just turn them on
)
As far as the model goes, one could simply remove "extends Shuffler_Model" from each class and it would be entirely usable in another application, you'd just have to implement your own persistence, forms, user interfaces, etc. But if there was no working application noone would notice it exists. On the other hand Symfony has "admin generators" that do all this and people still consider it a framework. At some point I plan to do video tutorials on how to add new modules, types of products, etc. For example if someone's product is so complex it requires custom PHP coding, we'd have interfaces setup for that, as well as video tutorials walking people through it, etc.
As of now you can click on a product and add it to multiple categories. Oooh, Aaah.... http://demo.metator.com/products (and also check off & delete multiple products at once)
I guess next I should focus on "add to cart" & "checkout". Regarding configurable products, I'd rather call it "product" and "options"... If its called product & master product in the code thats fine I guess but the user shouldn't even have to make a distinction, they should be called "products" on the screen, and they should be able to add options at any time.. These would be persisted in the product table. When browsing the products in the admin panel they could choose to filter out "options" to see just the "master products". I guess there could be some way of converting an option to a product and vice versa.
In Magento an option has an "input type" (radio, select, checkbox), some validation rules (required or not), a name (color) some values(red, blue) and each value can alter the price (add/subtract fixed $ amount/percentage amount).
On the other hand if you use a configurable product, instead of product options in Magento, you get to track inventory for red shirts vs blue shirts, use different SKUs, etc. Users like tracking the inventory but hate creating the SKUs (most users)
As far as the model goes, one could simply remove "extends Shuffler_Model" from each class and it would be entirely usable in another application, you'd just have to implement your own persistence, forms, user interfaces, etc. But if there was no working application noone would notice it exists. On the other hand Symfony has "admin generators" that do all this and people still consider it a framework. At some point I plan to do video tutorials on how to add new modules, types of products, etc. For example if someone's product is so complex it requires custom PHP coding, we'd have interfaces setup for that, as well as video tutorials walking people through it, etc.
As of now you can click on a product and add it to multiple categories. Oooh, Aaah.... http://demo.metator.com/products (and also check off & delete multiple products at once)
I guess next I should focus on "add to cart" & "checkout". Regarding configurable products, I'd rather call it "product" and "options"... If its called product & master product in the code thats fine I guess but the user shouldn't even have to make a distinction, they should be called "products" on the screen, and they should be able to add options at any time.. These would be persisted in the product table. When browsing the products in the admin panel they could choose to filter out "options" to see just the "master products". I guess there could be some way of converting an option to a product and vice versa.
In Magento an option has an "input type" (radio, select, checkbox), some validation rules (required or not), a name (color) some values(red, blue) and each value can alter the price (add/subtract fixed $ amount/percentage amount).
On the other hand if you use a configurable product, instead of product options in Magento, you get to track inventory for red shirts vs blue shirts, use different SKUs, etc. Users like tracking the inventory but hate creating the SKUs (most users)
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Shopping cart framework
Ok, I just prefer requiring the fewest customizations.josh wrote:I recommend turning on short tags. There is a zend way to work around them being off, I can't be bothered to research it at the moment (this is an area of much holy war so I'll be flexible if you have a differing opinion, but for now just turn them on)
My point was that we make it possible to use the base layer in other frameworks, not that we actually implement it. You may need to make a bunch of changes for ZF2 soon ... so reasonable independent is probably good.josh wrote:As far as the model goes, one could simply remove "extends Shuffler_Model" from each class and it would be entirely usable in another application, you'd just have to implement your own persistence, forms, user interfaces, etc. But if there was no working application noone would notice it exists. On the other hand Symfony has "admin generators" that do all this and people still consider it a framework. At some point I plan to do video tutorials on how to add new modules, types of products, etc. For example if someone's product is so complex it requires custom PHP coding, we'd have interfaces setup for that, as well as video tutorials walking people through it, etc.
You are pretty far down the road on your design, so keep at it. The thing I was mentioning (I guess) what that I have found that distinguishing between things you can purchase and things that organize the things you can purchase has worked for me in the past. A Master Product is not something you can purchase -- unlike a SKU. It is much more like a Category in that it combines like SKUs into a group.josh wrote:I guess next I should focus on "add to cart" & "checkout". Regarding configurable products, I'd rather call it "product" and "options"... If its called product & master product in the code thats fine I guess but the user shouldn't even have to make a distinction, they should be called "products" on the screen, and they should be able to add options at any time.. These would be persisted in the product table. When browsing the products in the admin panel they could choose to filter out "options" to see just the "master products". I guess there could be some way of converting an option to a product and vice versa.
In Magento an option has an "input type" (radio, select, checkbox), some validation rules (required or not), a name (color) some values(red, blue) and each value can alter the price (add/subtract fixed $ amount/percentage amount).
On the other hand if you use a configurable product, instead of product options in Magento, you get to track inventory for red shirts vs blue shirts, use different SKUs, etc. Users like tracking the inventory but hate creating the SKUs (most users)
(#10850)
Re: Shopping cart framework
Interesting food for thought, however I pictured it the other way... the user "purchases" the product and the options are just options.. You don't actually purchase the options you purchase the product itself.Christopher wrote: The thing I was mentioning (I guess) what that I have found that distinguishing between things you can purchase and things that organize the things you can purchase has worked for me in the past. A Master Product is not something you can purchase -- unlike a SKU. It is much more like a Category in that it combines like SKUs into a group.
However what you point out is a different paradigm I have seen before. For example if you sell Jets, you might want a "category" called Boeing 7xx series (much like a product), but the actual products are things like "Boeing 747 with Pratt & Witney Engines, Garmin Navigation, Delta Airlines Paintjob." First the store owner wants to show them a "product" and sell them on it, then later, they want to get into the nitty gritty details that determine exact pricing, at which point the user is presented with something they can purchase.
I recorded a video which is an intro to developing in this code base. I am rendering & uploading now.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Shopping cart framework
I think we are saying the same thing. I would say that the user purchases a SKU. The options are just ways to organize SKUs in a user friendly way.josh wrote:Interesting food for thought, however I pictured it the other way... the user "purchases" the product and the options are just options.. You don't actually purchase the options you purchase the product itself.
I think the more common example is apparel. Clothes and shoes come in styles, sizes and colors. Each available style/size/color combination is a SKU. To me it is not much different to organize a SKU as "womens" and "sports" than it is to organize it as "small" and "red". Any of these qualities (which is what I usually consider them) are ways to SELECT SKUs and organize them on the page for the user. The fact that those ways to organize SKUs happen at different levels in the hierarchy of pages the user clicks through is irrelevant to me.josh wrote:However what you point out is a different paradigm I have seen before. For example if you sell Jets, you might want a "category" called Boeing 7xx series (much like a product), but the actual products are things like "Boeing 747 with Pratt & Witney Engines, Garmin Navigation, Delta Airlines Paintjob." First the store owner wants to show them a "product" and sell them on it, then later, they want to get into the nitty gritty details that determine exact pricing, at which point the user is presented with something they can purchase.
(#10850)
Re: Shopping cart framework
Ok so there should be a distinction between product and SKU. You should have one product, with a few options. Behind the scenes the options are enumerated in all possible combinations and the SKUs are created. Inventory would be tracked per sku not per product. Users will create SKUs from the product page or product import, but there will be a separate screen where they can go click on the SKUs, and update the inventory (or they could get to this screen from the product screen). I like that concept, it allows different modules to request different SKUs to be created, and treats the SKU as a first rate object. SKU in fact stands for stock keeping unit, which implies the coupling to inventory. The relationship between products and SKUs would then be 1:n I guess, 1 product to 1 or more sku(s). This additional complexity should be transparent to the user who wants "simple products" though.
Here's a video, I added SKU (to the product model, product grid, product form, database, and data mapper).
http://metator.com/video1.mp4
There was a second video but there turned out to be no audio. It is adding SKU as an import field, its pretty straight forward though if you just read the code & unit tests. I'll record more later.
Here's a video, I added SKU (to the product model, product grid, product form, database, and data mapper).
http://metator.com/video1.mp4
There was a second video but there turned out to be no audio. It is adding SKU as an import field, its pretty straight forward though if you just read the code & unit tests. I'll record more later.
Re: Shopping cart framework
I've added wiki pages to provide written documentation to accompany these videos. Actually the written documentation was created a year or more ago, I should have added this to the code wiki earlier.
http://code.google.com/p/metator/wiki/Development - how the app is layered
http://code.google.com/p/metator/wiki/CRUD - high level interactions that happen for a CRUD transaction
http://code.google.com/p/metator/wiki/Grid - the grid framework that handles the "listing" of models (aka the R in CRUD)
http://code.google.com/p/metator/wiki/Development - how the app is layered
http://code.google.com/p/metator/wiki/CRUD - high level interactions that happen for a CRUD transaction
http://code.google.com/p/metator/wiki/Grid - the grid framework that handles the "listing" of models (aka the R in CRUD)
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Shopping cart framework
I am looking through the code as I get time. But you have a large many layered codebase that is customized/workaround'd on top of Zend to exactly fit the way you work -- not sure if I will get through it all. Keep going! 
(#10850)
Re: Shopping cart framework
I'm not sure I would agree that I've "worked around" anything in Zend, other then the fact I use my own bootstrap file instead of using the Zend_Application to bootstrap it.
I am using a lot of layering & custom code though
I won't argue that.
Users can now add items to their cart. oooh, ahh.
I am using a lot of layering & custom code though
Users can now add items to their cart. oooh, ahh.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Shopping cart framework
I was a little surprised you left as much ZF in as you did. Recode a few functions here and there, use PDO in Shuffler, and you would shed a lot of pounds. 
(#10850)