Shopping cart framework
Moderator: General Moderators
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Shopping cart framework
There are many general purpose CMF, and lower level frameworks, such as Zend, CodeIgnitor, etc.
Where are all the specialized frameworks? It would be nice to have a shopping cart framework which provided bare-bones functionality and customized workflow, ordering sequences, shipping, receiving, etc was provided via plugin/extensions.
Have you ever considered building something like this? What are some points of contention you have experienced in using existing SC solutions??? Obviously some examples of extension points are shipping modules. Payment gateways...etc...
I'm interested in hearing any opinions on the matter, experiences, ideas, etc?
Cheers,
Alex
Where are all the specialized frameworks? It would be nice to have a shopping cart framework which provided bare-bones functionality and customized workflow, ordering sequences, shipping, receiving, etc was provided via plugin/extensions.
Have you ever considered building something like this? What are some points of contention you have experienced in using existing SC solutions??? Obviously some examples of extension points are shipping modules. Payment gateways...etc...
I'm interested in hearing any opinions on the matter, experiences, ideas, etc?
Cheers,
Alex
Re: Shopping cart framework
I've thought about making one. If you want to do it with TDD & Zend Framework I'm all in. A big one would be new product types. There could be an interface for adding a product type, and if someone extends and adds a new product type, they should be forced to implement methods that allow that type of product to be used in a product import/export (big problem with Magento, they keep adding hot features that don't work with the import, so they exclude power users)
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Shopping cart framework
So why haven't you? No time?I've thought about making one.
Not my first choice in frameworks, but from an OSS/Marketing stand point it makes a lot of sense, and it settles any in-group bickering over best framework, etc. As for TDD, I prefer writing specs on paper first, but they can probably easily be translated into "tests" I am sure.If you want to do it with TDD & Zend Framework I'm all in.
By product "type" you mean like Drupal content type? Basically a table with custom fields, like adding WIDTH-HEIGHT-LENGTH or WEIGHT???could be an interface for adding a product type, and if someone extends and adds a new product type
Cheers,
Alex
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Shopping cart framework
Do you mean something like a UML graph?PCSpectra wrote:[...] I prefer writing specs on paper first [...]
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Shopping cart framework
No more like a BDD story:Do you mean something like a UML graph?
http://blog.dannorth.net/whats-in-a-story/
Specifications (in my context) are analogous to scenarios mentioned in the link above. Basically they are the individual behaviors which I would verify if implementing specifications and BDD practices.
Cheers,
Alex
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Shopping cart framework
Oh goody, something new to read about. 
Re: Shopping cart framework
No comment. You can use your imagination here ... maybe I thought of the idea 5m before you posted... maybe I've been thinking about it for 5yrs and am lazy? .... rather than trying to list all the reasons why not to do it.... id rather only think of reasons why i should.PCSpectra wrote:So why haven't you? No time?
What's your first choice? I think symfony even has a shopping cart component, but the actual "cart" part is relatively easy to implement, and if that one had enough features we wouldn't be proposing this. One of the 2 big reasons I like Zend is not a marketing stand point, but rather a legal stand point & a quality stand point. They require contributor agreements so later on you don't get a cease & desist letter signed by 150 developers because you made a few bucks off their contributions. It is also extensively unit tested which is a big factor for me. When I said TDD I don't care if its "test last" or "test first", but we should have a strict policy on tests like ZF does. In my opinion I should be in charge of deciding if it has "enough" tests, but who ever else is participating would help to vote on if a component is even "welcome" in our framework (and then, if it is welcome, I would have the power to veto the addition for reasons of test coverage, test quality, stability, etc..)Not my first choice in frameworks, but from an OSS/Marketing stand point it makes a lot of sense, and it settles any in-group bickering over best framework, etc. As for TDD, I prefer writing specs on paper first, but they can probably easily be translated into "tests" I am sure.
So TDD could be optional. But I think "documentation first" needs to be a rule. Why build what can't be explained to the target user? I've talked to software veterans and the general opinion is that writing documentation before you begin (either targeted at humans, or in the form of unit tests) makes the project go a lot smoother. It also allows us to vote on whether the complexity & behavior is "welcome" to our repository. Instead of calling it documentation, calling it a "proposal" makes it more widely understood. That's what ZF does.
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.By product "type" you mean like Drupal content type? Basically a table with custom fields, like adding WIDTH-HEIGHT-LENGTH or WEIGHT???
At some point our framework could provide this functionality, but at first we'd be wise to stick to simple products and evolve it. No point in multiple product types until you have at least 1 product type working start to finish (payment methods, etc..)., and some actual real world users to provide their feedback.
The other question is at what level of abstraction would this be at? Are we building a framework & application, a sort of dichotomy? Or are we trying to not implement the application? Or is it really just an application (and not a framework)
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Shopping cart framework
This sounds interesting. Does it really need to be framework specific? Is there anything that would be tied to a frameworks Controller architecture? An Adapter could be required (and trivial to write) for the Models. It seem like a standalone piece -- even if it used components from existing frameworks.
I 2nd having test as a requirement.
I 2nd having test as a requirement.
(#10850)
Re: Shopping cart framework
Well, if we're writing an application that is supposed to run out of the box, it will need to be coupled with at least one framework I would imagine.Christopher wrote:Does it really need to be framework specific? Is there anything that would be tied to a frameworks Controller architecture?
Personally I like to solve that problem by using a data mapper, but in any scenario I think its important to defer these decisions. In the past I've gone down the route of being dogmatic by writing adapters, when there is only one framework I wanted it to work with anyways. In the past I've found trying to write the adapter at the same time as the application was a burden, and I've found its easy enough to just focus on your models, and later on if/when the need for multiple frameworks arises, its easy enough to "sprout a new class" for the adapter and move methods over to it. The exception of course being when the queries are located in the model instead of in the data mapper. Then it tempts you to write hacks like this:An Adapter could be required (and trivial to write) for the Models.
Code: Select all
function load()
{
if($this->identityMap()->has($this))
{
// @todo | a hack to get around the finder being coupled to the model
$newThis = $this->identityMap()->get($this);
$this->setTitle($newThis->getTitle());
return;
}
}
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Shopping cart framework
I didn't mean anything by that comment, I was simply asking, incase, you found alternatives, difficulties, etc.No comment. You can use your imagination here ... maybe I thought of the idea 5m before you posted... maybe I've been thinking about it for 5yrs and am lazy? .... rather than trying to list all the reasons why not to do it.... id rather only think of reasons why i should.
Implementing a truly fleixble eCommerce solution is much like building Joomla/Drupal but gear towards eCommerce not general CMS.
My own controller framework, of course. Zend is just over engineered, IMO. I have yet to extract the dispatching from the core front, but thats coming, and even when I do, the codebase is a fraction of Zend implementation in terms of SLOC. I don't expect anyone to use it, I am simply replying to your question, what is my first choice.What's your first choice?
I implemented a very simple generic TDG and that solves 95% of all SQL queries, 100% so far in the latest project. Models are not required, but you could easily use Doctrine, etc. As for views, there is a generic View adapter, which can use Smarty, Native Syntax, etc.
Thats why I don't really call it a MVC framework, as it's really just the very basic core components in a controller architecture, front controller, a few actions, plugins/intercepting filters, dispatcher, routing, etc. Very minimal. The model and view are left to the client developer, if used at all.
Win-win. Most general frameworks are BSD, so licensing is rarely a concern for me. Quality, well, again, it is my personal opinion they over-engineered a lot of things (ie: controller architecture), a lot of extraneous checks, etc. That being said, it's quality is probably highest of all frameworks I have seen to date.One of the 2 big reasons I like Zend is not a marketing stand point, but rather a legal stand point & a quality stand point
Interesting. Isn't that was BSD eliminates? Basically the idea is free for everything and anything just don't remove copyright notices?They require contributor agreements so later on you don't get a cease & desist letter signed by 150 developers because you made a few bucks off their contributions
yes I know it is. Whats the code coverage like? 100%? My only concern is, we all know people can write unit tests for just about any code with enough effort. Therefore having unit tests alone is not enough of a selling point for me. I guess if I am not the one writing them I guess it's OK.It is also extensively unit tested which is a big factor for me
I've worked on a few projects where the tests were so complicated, used so many stubs, writing/maintaining the test took more effort than implementing code. However, I will take your advice on the fact that Zend tests are done right and of high quality, as they clearly have a talented team of developers working on the software. This point of mine is moot, I am just saying for the sake of conversation, so just ignore it.
Well, my general opinion is test everything. If you don't have 100% code coverage of the SUT, something needs to be refactored, IMO. This is why I steered towards BDD I think, partially because I could never determine if I had enough tests or was testing the right thing. Writing specs inconjunction with code coverage make that decision easy. Basically run your SUT under all given/known contexts and execute all paths.When I said TDD I don't care if its "test last" or "test first", but we should have a strict policy on tests like ZF does. In my opinion I should be in charge of deciding if it has "enough" tests, but who ever else is participating would help to vote on if a component is even "welcome" in our framework (and then, if it is welcome, I would have the power to veto the addition for reasons of test coverage, test quality, stability, etc..)
As for addressing control of unit tests, that is a political issue, something we would have to discuss in more detail. Suffice it to say, if I understand exactly what you desire, I wouldn't have much an issue of with it. Of course, more detail needs to be fleshed out.
I write a lot of documentation in initial phases. I plan a lot on paper, but usually on napkins, etc.So TDD could be optional. But I think "documentation first" needs to be a rule. Why build what can't be explained to the target user? I've talked to software veterans and the general opinion is that writing documentation before you begin (either targeted at humans, or in the form of unit tests) makes the project go a lot smoother
Another reason I started following BDD was the story writing, specififying behaviors which could possibly be translated into english form as a document for clients to sign off on. I found it could serve multiple purposes, even to be used with an estimate calculator I had built.
Define framework in this context? A series of API specialized for eCommerce, that a developer ties to gather and creates the interfaces for? Does it come with a backend? Then client then implements the front side using the backend API, much like a web service?The other question is at what level of abstraction would this be at? Are we building a framework & application, a sort of dichotomy? Or are we trying to not implement the application? Or is it really just an application (and not a framework)
Cheers,
Alex
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Shopping cart framework
Do you want to build an e-commerce application or an e-commerce library?josh wrote:Well, if we're writing an application that is supposed to run out of the box, it will need to be coupled with at least one framework I would imagine.
I agree on the DataMapper, but it needs to connect to the database somehow. That's why I was thinking that simple Adapters at the low level would all the complex stuff on top to just work.josh wrote:Personally I like to solve that problem by using a data mapper, but in any scenario I think its important to defer these decisions. In the past I've gone down the route of being dogmatic by writing adapters, when there is only one framework I wanted it to work with anyways. In the past I've found trying to write the adapter at the same time as the application was a burden, and I've found its easy enough to just focus on your models, and later on if/when the need for multiple frameworks arises, its easy enough to "sprout a new class" for the adapter and move methods over to it. The exception of course being when the queries are located in the model instead of in the data mapper. Then it tempts you to write hacks like this:
The reason these hacks are tempting is the user "queries" for a model, using a model. That is they create a model and pass an id, and then ask that model to "find" itself and load the rest of it's fields. That makes less sense than having the engine object instantiate the car object, instead of introducing a factory object.
(#10850)
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Shopping cart framework
How would you use a data mapper? Can you elaborate with a quick example, say for an entity like 'product' with the following fields:I agree on the DataMapper, but it needs to connect to the database somehow. That's why I was thinking that simple Adapters at the low level would all the complex stuff on top to just work.
Code: Select all
product:
id_primary, price, title, bodyI have only experimented with data mappers, I believe josh had one implemented a while back, but I have almost always favoured TDG myself.
Cheers,
Alex
Re: Shopping cart framework
That's something to be proud of but is of little importance when deciding on a framework to use. ZF is higher SLOC because it does more.PCSpectra wrote:the codebase is a fraction of Zend implementation in terms of SLOC.
No. I can steal another developers work and license it under any license that I want to. If I indemnified myself and gave it away for free, chances are the people who actually profited off the code are getting sued, regardless of who told them it was ok to do.Interesting. Isn't that was BSD eliminates?They require contributor agreements so later on you don't get a cease & desist letter signed by 150 developers because you made a few bucks off their contributions
How would you use a data mapper? Can you elaborate with a quick example, say for an entity like 'product' with the following fields:
Code: Select all
$model = $mapper->findById( 5 );
$model->setTitle('updated');
$mapper->save($model);
The goal is never 100% code coverage. Like you said any idiot can acheive 100% code coverage, that doesn't mean you have "enough" tests. That's why I think I should be in charge of the testing dept if we're to do this, because I understand this concept very well. Professional enterprises do not in fact measure code coverage, they measure path coverage. Basically "enough" can be defined as 'when someone can read the unit test and it reads like documentation'. (yeah - its a subjective concept because test coverage on trivial stuff is pointless, so test coverage as a percentage is a useless and even misleading measurement)yes I know it is. Whats the code coverage like? 100%?
Yes, there are many reasons that your tests can end up sucking. Generally you can simplify the reason for them sucking as "the developer was in the testing mind frame and wrote it like a test and not like an 'executable specification'"I've worked on a few projects where the tests were so complicated, used so many stubs, writing/maintaining the test took more effort than implementing code. However, I will take your advice on the fact that Zend tests are done right and of high quality, as they clearly have a talented team of developers working on the software. This point of mine is moot, I am just saying for the sake of conversation, so just ignore it.
Re-factoring comes _after_ test coverage not beforeWell, my general opinion is test everything. If you don't have 100% code coverage of the SUT, something needs to be refactored, IMO
If anyone wants to challenge me and show they have more control over testing, I welcome any contenders. There are many people here who are better and more knowledgeable than me and I'd welcome them to fulfill the roll (assuming that one - this project happens, and two - they show interest in fulfilling the role). It needs to be a single or few elected people though. If you take a free-for all vote, the majority rule is not going to know a good test from a bad test.As for addressing control of unit tests, that is a political issue, something we would have to discuss in more detail. Suffice it to say, if I understand exactly what you desire, I wouldn't have much an issue of with it. Of course, more detail needs to be fleshed out.
http://code.google.com/p/metator/
http://www.metator.com
I got .net too. It stands for "metadata editor". Stole the name from the 'CMS Bible', paid a pretty penny for the domain name too. I put the project summary as a shopping & content management platform.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Shopping cart framework
I don't test for everything, I typically test for a forced/known failure. I should have 100% coverage though, simply by specifying the behavior of the SUT, that should cause every single line of the SUT to execute and thus test all paths in a method.Re-factoring comes _after_ test coverage not before Also see my previous point - you don't want to test everything, and certainly not 100% code coverage of those components you do decide to test. I can make any project hit 100% code coverage and only have 10% path coverage, so its not even a measurement in the traditional sense. I can't take code coverage from one project and compare that to code coverage from another project, its not a real measurement.
I think we are getting a head of ourselves if what we are expecting is a community project. You purchased the domain, so instantly you have more ownership over anything that happens. Secondly, and perhaps more importantly, a name of a product is much like a business. If others are to assist in building brand awareness, they usually only do so (when not getting paid) when they/we all share a common vision. No one, that I know of had any say in name "metadata editor". It's not a name I would choose, as in my opinion, the name should reflect the purpose or intent of the software at least some what.I got .net too. It stands for "metadata editor". Stole the name from the 'CMS Bible', paid a pretty penny for the domain name too. I put the project summary as a shopping & content management platform.
What I usually prefer with partners is to sit down and have a brainstorming session where all of us throw in a few dozen keywords (adjectives and nouns), in this case:
- Super
- Fantastic
- Amazing
- Shop
- Cart
- Commerce
Everyone throws in as many as possible. Then try (as a group) to discover a name which everyone (or majority) likes, for example: SuperCart
Obviously domain names are of concern, so one common technique is to add latin suffixes, such as "UberCartatus". Once you establish that, you will likely have also developed a camaraderie amongst each other. Critical for success as a group.
From this point on you have several more brain storming sessions, about features, ideas, market saturation/competitor analysis, etc. After a week or two or three of hammering out details, it becomes apparent who should lead the project, as they tend to osmotically bubble to the top, either through assertion or assimilation; the latter usually being prefered.
Just my two cents.
Cheers,
Alex
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Shopping cart framework
I should note, none of the above was intended to sound condescending, I apologize if it sounds that way. I simply wanted to voice my concerns. I still encourage you to continue with development. I just checked out your source thus far, will offer any feedback I can.
Cheers,
Alex
Cheers,
Alex