Page 1 of 3

Shopping cart framework

Posted: Tue Oct 12, 2010 1:22 pm
by alex.barylski
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

Re: Shopping cart framework

Posted: Tue Oct 12, 2010 1:52 pm
by josh
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)

Re: Shopping cart framework

Posted: Tue Oct 12, 2010 3:09 pm
by alex.barylski
I've thought about making one.
So why haven't you? No time?
If you want to do it with TDD & Zend Framework I'm all in.
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.
could be an interface for adding a product type, and if someone extends and adds a new product type
By product "type" you mean like Drupal content type? Basically a table with custom fields, like adding WIDTH-HEIGHT-LENGTH or WEIGHT???

Cheers,
Alex

Re: Shopping cart framework

Posted: Tue Oct 12, 2010 3:35 pm
by Jonah Bron
PCSpectra wrote:[...] I prefer writing specs on paper first [...]
Do you mean something like a UML graph?

Re: Shopping cart framework

Posted: Tue Oct 12, 2010 5:00 pm
by alex.barylski
Do you mean something like a UML graph?
No more like a BDD story:

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

Re: Shopping cart framework

Posted: Tue Oct 12, 2010 6:32 pm
by Jonah Bron
Oh goody, something new to read about. :)

Re: Shopping cart framework

Posted: Tue Oct 12, 2010 7:06 pm
by josh
PCSpectra wrote:So why haven't you? No time?
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.
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.
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..)

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.
By product "type" you mean like Drupal content type? Basically a table with custom fields, like adding WIDTH-HEIGHT-LENGTH or WEIGHT???
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.

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)

Re: Shopping cart framework

Posted: Tue Oct 12, 2010 7:26 pm
by Christopher
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.

Re: Shopping cart framework

Posted: Wed Oct 13, 2010 4:34 am
by josh
Christopher wrote:Does it really need to be framework specific? Is there anything that would be tied to a frameworks Controller architecture?
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.
An Adapter could be required (and trivial to write) for the Models.
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:

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;
        }
        

}
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.

Re: Shopping cart framework

Posted: Wed Oct 13, 2010 11:56 am
by alex.barylski
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.
I didn't mean anything by that comment, I was simply asking, incase, you found alternatives, difficulties, etc.

Implementing a truly fleixble eCommerce solution is much like building Joomla/Drupal but gear towards eCommerce not general CMS.
What's your first choice?
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. :)

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.
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
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.
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
Interesting. Isn't that was BSD eliminates? Basically the idea is free for everything and anything just don't remove copyright notices?
It is also extensively unit tested which is a big factor for me
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. :)

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.
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..)
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.

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.
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
I write a lot of documentation in initial phases. I plan a lot on paper, but usually on napkins, etc. :lol:

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.
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)
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?

Cheers,
Alex

Re: Shopping cart framework

Posted: Wed Oct 13, 2010 12:00 pm
by Christopher
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.
Do you want to build an e-commerce application or an e-commerce library?
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.
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.

Re: Shopping cart framework

Posted: Wed Oct 13, 2010 12:22 pm
by alex.barylski
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.
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

product:
  id_primary, price, title, body
What would the code look like? Is the data mapper your model, or simply providing a DAL to the model? Can you implement say, a create() method for the model, with validations on the price not being ZERO, title less than 255, sanitized using htmlentities, etc?

I 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

Posted: Wed Oct 13, 2010 1:42 pm
by josh
PCSpectra wrote:the codebase is a fraction of Zend implementation in terms of SLOC.
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.
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
Interesting. Isn't that was BSD eliminates?
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.
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);
Just saying querying does not belong in the model, unless you want to beget hacks like the one a few posts back.
yes I know it is. Whats the code coverage like? 100%?
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)
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.
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'"
Well, my general opinion is test everything. If you don't have 100% code coverage of the SUT, something needs to be refactored, IMO
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.
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.
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.



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.

Re: Shopping cart framework

Posted: Wed Oct 13, 2010 3:53 pm
by alex.barylski
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 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.
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.
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.

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

Re: Shopping cart framework

Posted: Wed Oct 13, 2010 4:01 pm
by alex.barylski
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