Product Options

SapporoGuy wrote:lolo, didn't know that is how Magneto or any other cart did it.

You don't need to make all the columns an attribute. Just the options essentially.
The only thing I can see being complicated is only when you put together the product in the admin.

But is the magneto way that much more complicated than what you are all trying to figure out?

If you were to use your approach then you might as well just make a product for every variation of that product and not even have any product options at all. In fact, most stores that can't figure out product options seem to do this. But the idea behind product options is to group variations of an product into one product. Not only for user friendliness and ease of administration but also for SEO (less duplicated content).

d7a7z7e7d wrote: Making sense now?

well somewhat now that you added the javascript which you never mentioned before, but you still don't explain how that sku gets posted back to the php. Simply building an array doesn't help at all you'll have to build a hidden input or somthing to pass the sku back along with everything else based on the selected options.

SapporoGuy wrote: But is the magneto way that much more complicated than what you are all trying to figure out?

well it's not that much more complicated, but you still have to manage option combinations and dependent options somehow which is what we are working on. The biggest thing is to move to a magento like system would be a major rewrite of a vast majority of the code which I just don't see happening.

Xsecrets wrote:

d7a7z7e7d wrote: Making sense now?

well somewhat now that you added the javascript which you never mentioned before, but you still don't explain how that sku gets posted back to the php. Simply building an array doesn't help at all you'll have to build a hidden input or somthing to pass the sku back along with everything else based on the selected options.

I'm pretty sure I mentioned using javascript fairly early into our conversation:

d7a7z7e7d wrote:You now have all of the data necessary for the user interface to dynamically enable or disable the appropriate options based on stock. As you can see from the results of the 2nd query, you have the option_value_ids for each sku. So with a little bit of javascript in conjunction with the results of the first query, you should be able figure out which options need to be toggled.

I assumed you'd be able to figure out where I was going with that but perhaps I didn't make it clear enough. Anyhow, I see that you are figuring out the remaining bits such as the hidden input without any further clarification which tells me that you are starting to wrap your head around the idea and hopefully I won't have to elaborate on the minor details any further. The general idea is there and now that you understand how it all works, would you like to offer any alternate solutions or have any further suggestions or comments on this one?

And just to clarify, the only thing you'd need to pass back would be the sku_id and quantity.

d7a7z7e7d wrote:

d7a7z7e7d wrote:You now have all of the data necessary for the user interface to dynamically enable or disable the appropriate options based on stock. As you can see from the results of the 2nd query, you have the option_value_ids for each sku. So with a little bit of javascript in conjunction with the results of the first query, you should be able figure out which options need to be toggled.

I assumed you'd be able to figure out...

well to be fair it's quite a jump from figuring out dependent options to building an array and populating a hidden input. So it looked as I stated like you were doing stuff for no good reason since you were making your second query but never using it.

Ah well, my original intent was to just to suggest a schema for everything else to be built on and so that is where I started. It seems like we've pretty much covered it from start to finish. Now the fun part would be building the admin GUI for it

by d7a7z7e7d » Sat Nov 20, 2010 2:32 pm

Ah well, my original intent was to just to suggest a schema for everything else to be built on and so that is where I started. It seems like we've pretty much covered it from start to finish. Now the fun part would be building the admin GUI for it

Don't get me wrong, I do like your idea. And essentially, it was your SQL layout that I was thinking about when I posted my comment.

by d7a7z7e7d » Sat Nov 20, 2010 6:02 am

SapporoGuy wrote:
lolo, didn't know that is how Magneto or any other cart did it.

You don't need to make all the columns an attribute. Just the options essentially.
The only thing I can see being complicated is only when you put together the product in the admin.

But is the magneto way that much more complicated than what you are all trying to figure out?


If you were to use your approach then you might as well just make a product for every variation of that product and not even have any product options at all. In fact, most stores that can't figure out product options seem to do this. But the idea behind product options is to group variations of an product into one product. Not only for user friendliness and ease of administration but also for SEO (less duplicated content).

Actually, not the way I was thinking. I don't know how any other cart does it. and have never given it any thought to it until last night.

The way I was thinking is that for the catalog side you still present the product as is and just use a few different lives of SQL instead of how it is being done now. So in reality, both come out the same in regards to seo and such. It's just how each product is built from the SQL or the presentation.

by Xsecrets » Sat Nov 20, 2010 8:35 am

SapporoGuy wrote:
But is the magneto way that much more complicated than what you are all trying to figure out?

well it's not that much more complicated, but you still have to manage option combinations and dependent options somehow which is what we are working on. The biggest thing is to move to a magento like system would be a major rewrite of a vast majority of the code which I just don't see happening.

Any change to the current system is going to require a re-write of the system. The point is to make the change once and put in place a system that is easy yet sophisticated enough to handle any type of product that you throw at it. If it requires a huge re-write in the beginning than I'd imagine it would be better to do now versus later when things might be more complicated. Which is another reason why I'm suggesting that opencart should move to a ecommerce framework instead of being just a better cart.

@@@
Once again, I do like the sku idea. I'm just trying to throw out some ideas to get thoughts flowing and trying to get you all to think in a different manner than from possibly the way you may be thinking. Essentially, looking at this from all possible angles. I just read today that LibreOffice (err, what ever it's name is now) mentioned recently that they are going to focus on the document rather than the software. Sometimes, a change of perspective can create creativity. By doing so can make all the difference.

what would you consider an "ecommerce framework"?

I was just wondering the same thing X - OC is already running on an MVC architecture...

Errr, yeah, framework ...

So is opencart = Zend ? Both are MVC frameworks. This is what I am not trying to say.

I do realize that oc is MVC-L and this is why I landed here. MVC is a fundamental framework but yet without resorting to a wikipedia based answer I'm just going to say that MVC is a basic pattern to follow as in a coding practice.

So, I'm going to explain what I mean without using a dictionary and quoting things.

Going from a layman' s point of view (which is what your average downloader is) I'd say in the php world cakphp and codeignitor, for ruby Ruby on Rails (RoR) and for Python Django all of which are frameworks to build your application upon.

So, for the standard person hosting a site using the layman's viewpoint opencart is not a framework.

Now, what I'm recommending is that opencart should move towards is an end user's framework.
- which is basically, code that is based on a framework -- in which case opencart is MVC-L
- however, is not necessarily a true application framework like cakePHP or RoR which requires you to build, scaffold and rake your application
- but which put you into the category of Modx-cms

At the moment opencart has huge mountain to climb to gain a large market share. Of course, this is all relative to what Daniel's vision of what he would like to do with opencart.

My vision for opencart is that becomes one of the leading php solutions to turn to in the php world.
Ruby has spree
Python has never did find one that caught my eye ...
Php has magneto, oscommerce, zencart, and then various other carts. I sort of stumbled upon opencart after doing hours of googling.

So, in order to be a top alternative you either build a better mouse trap OR you market and place yourself differently to put you up front center of attraction.

modx had to find a way to gain market share from (err forgot first name)-mambo-joomla, wordpress, drupal and others, yet they carved out a sweet spot in the market by placing themselves as a CMS framework. They are not a cms but yet a cms.

Sorry for all the modx references ... I thought they would be an easy to understand reference.

But back to my vision.

At the moment, oencart is very capable and fairly well coded "cart". But is this enough to gain market share and awareness. Does it have enough pull to be pitted against magneto or zencart? Not yet ... since oc isn't in your face on the net thereby not the first to be pondered over.

So, my idea of "framework".
Redesign opencart --- err, basically pull most of the code out of oc and move it into modules that can be downloaded.

Have the core cart be so basic in functionality that you have to download most modules to design your own cart to match your own flow. Rather than trying to mod oc into what you need it to do.

You could even have the login be open enough that you could tweek the login process to allow it interface with most standard cms's out there.

Thus the framework is just the core cart functionality of product display through checkout.

Like modx which has no install data. The admin is fully functional which you then download a sample site and start from there or you build your front end to the way you think it should work.

I have not seen a cart that is not bloated.

with the framework I'm imagining:
- You would have an observer / hook functionality which would allow developers to develop almost anything
- You could design your own checkout process
- You could swap out the current design system with a template system like smarty (errr, just saying)
- updates and newer versions would have less of an effect on custom code
basically allowing almost 100% presentation control.

Just imagine the power of you would have in your hands as a regular user of the system. You still get the normal oc system as it is today as a sample cart but yet you could just pick and choose what you want to have on your server.

The admin would be more of Wordpress/modx backend even though I think the incoming messaging is annoying.

Is there a cart out there at the moment that does this?

NB: this is a redbull powered post

To answer your question yes opencart is based on an true MVC framework much like codeignter cakephp zend framework etc. It's just that it was written by Daniel, and is quite a bit simpler than any of the previously mentioned frameworks. Basically have a look in the system folder and you'll find a full framework.

Everyone who mentions framework from a non php framework point seems to mention modx I've never really used it, but to me it seems kind of crazy to expect the average downloader to be able to do coding weather it's in the admin or in actual php files.

To do what you suggest about making everything configurable is not quite so easy. Have a look at Magento if you don't believe me. Their big hype was that everything and anything can be done with modules and that it will all be insulated from upgrades, however we see what kind of a mess that turned out to be, and on top of that it didn't work. Try to get a mod of any substance even a them from an early version to work on a recent version it's not happening.

I do however believe there needs to be a better set of observers/hooks for the mod makers, and I would like to see a mod install system where a user can do it from the admin without having to resort to ftp. Both of those ideas are being discussed and I imagine will probably seep in around v2.0. I do not ever forsee a time when a standard user could completely customize the checkout process. There is no cart out there that allows that level of easy customization, and there's a good reason it's just not possible to make that level of customization easy.

I'd like to point out also just how slow Magento is running compared with OC loading your average page. It has that much bulk added to it to do all the fancy stuff that it does that it doesn't respond very well at all. Don't get me wrong, some of the Magento features are really great, but most people prefer speed to a fancy little trick on a page

Xsecrets wrote:To answer your question yes opencart is based on an true MVC framework much like codeignter cakephp zend framework etc. It's just that it was written by Daniel, and is quite a bit simpler than any of the previously mentioned frameworks. Basically have a look in the system folder and you'll find a full framework.

oc != zend ||cakephp
oc || zend || cakphp == framework

Both statements are true.
Even oscommerce is a framework if you think about it.

Thus I used the word "layman" to mention that people view the word "framework" differently.
I am using the framework in a layman's way and also to refer to a way to differentiate oc from other carts.

Xsecrets wrote: Everyone who mentions framework from a non php framework point seems to mention modx I've never really used it, but to me it seems kind of crazy to expect the average downloader to be able to do coding weather it's in the admin or in actual php files.

Modx is not for every one. I recommended a friend to use Wordpress over modx (although I prefer modx), by the way, this same person just got elected as a State Representative (USA).

But, I'd suggested just checking it out for the merits that it does provide.
It is highly biased for the designer/coder in the beginning and the later comes sort of close to WP over all.
While I'd say WP is great for getting something out of the door tonight and bother later with trying to do this or that later. Modx takes the opposite approach. Take some time now to copy/paste things doable tonight.
You do not have to code to use it. You don't even have to use FTP to use it (well, out side of getting it on your server).

Being able to inject your own code is pretty revolutionary.

Xsecrets wrote:To do what you suggest about making everything configurable is not quite so easy. Have a look at Magento if you don't believe me. Their big hype was that everything and anything can be done with modules and that it will all be insulated from upgrades, however we see what kind of a mess that turned out to be, and on top of that it didn't work. Try to get a mod of any substance even a them from an early version to work on a recent version it's not happening.

I do however believe there needs to be a better set of observers/hooks for the mod makers, and I would like to see a mod install system where a user can do it from the admin without having to resort to ftp. Both of those ideas are being discussed and I imagine will probably seep in around v2.0. I do not ever forsee a time when a standard user could completely customize the checkout process. There is no cart out there that allows that level of easy customization, and there's a good reason it's just not possible to make that level of customization easy.

I agree, and really don't think you want to make everything configurable.
Basic cart functionality + modular extensions + simple hacks is the basic design idea.

I have only installed and looked at the directory structure of Magneto. That was enough to make my decision to go with opencart. So, yeah, I can see why people would think that magneto is a mess.

However, to be fair, I do not know how they tried to implement what they were trying to do nor the methods they used.

Since, OC is a MVC framework, I really think that you could abstract it even more, add in the observer/hooks, and do what magneto didn't do.

As for a complete customized checkout process.
IF it were a module that hooked into the observer class then yes, you could almost get a different checkout process because the original checkout process was abstracted from the core functionality. At the moment ... I'd hate to tamper too much since I'd probably spend about the same amount of time that I did with oscommerce to accomplish this.
So, yeah, it's not easy to do with the current code.

I do agree that this is not really for the 1.x branch.
I do also agree that this would be a great 2.x branch goal

Can we get a mod to split this thread?
I took it too much of tangent and the original topic really does deserve being run over.

SapporoGuy wrote:Can we get a mod to split this thread?
I took it too much of tangent and the original topic really does deserve being run over.

Nonsense! We are still discussing product options to some degree aren't we?

Thanks and sorry for going on a tangent

I have to throw my support behind d7a7z7e7d for the sku methodology. This issue has been a part of the wholesale distribution and manufacturing industries for decades (3 that I know of) along with the propietary and custom software that they use and they all use the sku.

The whole idea of an sku, stock keeping unit, is to keep track of inventory for an item received and sold. Items essentially have three forms: absolute items that will never change, items that can be configured, items that can be modified by the inclusion or exclusion of other components. When an item is received from the manufacturer it is always in one of those three states, and all items must come from a manufacturer, somewhere. So there are basically three types of items that you'd be able to create: item, configurable item, kit item. I'll stick with the current theme of the T-shirts and computers and try not to elaborate to much.

Green T-shirts - Small
Green T-shirts - Medium
Green T-shirts - Large
Each T-shirt purchased from the manufacturer would have a specific sku identifying it as a specific item (Green T-shirt - Small), most often using the manufacturer's sku. Now you want to add value to those because a customer asked if you could put a custom message on the front of it. You decide you want to put customized messages on some and not others, some only the front others both front and back and others the back only, based on customer requests; I Love Mom, I Love off-roading, etc... This is considered a configurable item. You can sell it as a standard Green T-shirt which would have one sku or add value and put a custom message on it which would have a different sku. If you choose to put messages on both the front and back that would be another sku. You could use the sku from the manufacturer for the standard item and create your own sku for the customized ones and each individual sku has a specific price, stocking level and images. A computer is considered a kit item.

Computer Case
Power Supply
Motherboard
CPU
Memory - 4 GB
Hard Drive - 500 GB
Each computer component (cpu, motherboard, memory, etc...) has the ability to be sold as an individual item or as part of a parent item (assembled computer). Each of these type of items would be classified as having the ability to be a component item in the system, using a flag on each item. Each component item has their own sku and each assembled computer has its own sku as a kit item, which would only relieve inventory at the component level, not as a completed computer. A computer would be setup in the system as a kit and a kit only relieves inventory from each individual component, not the finished product, unless you normally assemble computers from the components and sell them.

So basically there are the three type of items, described above. The system has to be able to recognize each type of item when it is received or sold and properly add to or relieve the inventory based on the quantity. Regardless of how we want to think of it, the system has to be able to properly relieve inventory correctly and the most common method in use today is with a sku number.

Products would need to be setup with a flag (checkbox) for Component, one for Configurable and another for a Kit. The defaults would be false, indicating sold as is. A Configurable item would require one or more options. A Kit would require a bill of material, a list of items that make up that Kit item. Each sku can be setup based on any of a number of things; the manufacturers sku, color, message, size, etc... This is both the beauty and dilemma of the sku system; it provides for absolute identification of every item received or sold and it requires thought for setup and on going maintenance to keep it up. This is part of the reason most non-proprietary systems don't want to use it, because of the heavy maintenance. Unfortunately, in order to provide a flexible system, when it comes to products, you really have to either use the sku method or something extremely close to it that does the same thing - correct inventory management.

options already have their own qty.. with my options plus mod it adds weight, sku, image, misc info, and more.. so it is no big deal to add another field. That isn't really the point. This thread has gone off in the world of dependent options but have a lot more to take account of. 1.5.0 will come with global options as well as different option types (text, checkbox, file, etc) So there are additional fields that all need to gel together first that people have left out of their own option design patterns. That will likely not include dependent options, although if we use a system like the category "parent id" we could probably apply that to the options in some way. But first we need to get that step sorted

SapporoGuy wrote: But, I'd suggested just checking it out for the merits that it does provide.
It is highly biased for the designer/coder in the beginning and the later comes sort of close to WP over all.
While I'd say WP is great for getting something out of the door tonight and bother later with trying to do this or that later. Modx takes the opposite approach. Take some time now to copy/paste things doable tonight.
You do not have to code to use it. You don't even have to use FTP to use it (well, out side of getting it on your server).

Being able to inject your own code is pretty revolutionary.

I did install it locally and have a quick look and I agree the functionality is nice, but there is a reason that ecommerce packages are not written this way. You have to have a much more tightly integrated process for an ecommerce solution or it all falls apart. I figured modx is so configurable and great I would do a quick search and see what kind of ecommerce solutions they have and the only one I could find looked like a gigantic mess.

I agree, and really don't think you want to make everything configurable.
Basic cart functionality + modular extensions + simple hacks is the basic design idea.

I have only installed and looked at the directory structure of Magneto. That was enough to make my decision to go with opencart. So, yeah, I can see why people would think that magneto is a mess.

However, to be fair, I do not know how they tried to implement what they were trying to do nor the methods they used.

Since, OC is a MVC framework, I really think that you could abstract it even more, add in the observer/hooks, and do what magneto didn't do.

well Magento is based on MVC as well. they are using the zend framework.

As for a complete customized checkout process.
IF it were a module that hooked into the observer class then yes, you could almost get a different checkout process because the original checkout process was abstracted from the core functionality. At the moment ... I'd hate to tamper too much since I'd probably spend about the same amount of time that I did with oscommerce to accomplish this.
So, yeah, it's not easy to do with the current code.

if you have an idea how you could do this in a reasonable manner you could probably become an instant millionaire. As I stated above due to the very nature of ecommerce it's not so easy.

I have to say after looking over the schema proposed at the beginning of this thread I think with some tweaks it could make a very nice option system. It would of course have to be tweaked to accomidate the new option types, also you would have to figure out how to handle having only some of the options be a sku as mentioned above the large-green part of a tshirt would be a sku, but you don't want the text entry or file upload fields to be included in that sku. Plus I think I would rather have the arrays and such handled in php instead of javascript, but I think all those issues could be worked out for a nice system.

MVC is a "design pattern".. it is generalized as a "framework" but really just a pattern
OpenCart uses its own framework that takes pieces from multiple branded frameworks like CodeIgniter, yii, etc

So OpenCart is a "Framework" that uses the "MVC design pattern"

On the one hand, yes opencart could have been made on an existing framework, but some developers, like poets and artists, find more in creating and owning the complete package. It's like the soul of the "cart" application. Yes it could stand to be more robust. But the cart application is the main focus for now.