Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Kill cart library #214

Closed
philsturgeon opened this Issue Aug 20, 2011 · 28 comments

Comments

Projects
None yet
Contributor

philsturgeon commented Aug 20, 2011

Move to Spark.

Contributor

kylefarris commented Aug 23, 2011

Awwe... this actually kinda makes me sad since I'm using it in my cart application. But, I can deal with it being a Spark, I guess.

Contributor

timw4mail commented Aug 24, 2011

Is Spark mentioned in the user guide?

Contributor

kylefarris commented Aug 24, 2011

Yeah, I was thinking the same thing... A link to getsparks.org should be in the user guide and maybe the how-to.

Contributor

joelcox commented Aug 24, 2011

As long as Sparks is not integrated with CI, the cart probably won't be killed. No worries.

Contributor

philsturgeon commented Aug 24, 2011

We're integrating Sparks with 2.1 and there will of course be
documentation as and when that is done.

Contributor

wooptoo commented Oct 3, 2011

Keep the cart library as it is (after all, it works well) and allow adding more complex cart modules thru spark.

Keep the cart library please.

Personnally i agree to kill cart and move into sparks.

Contributor

marcosgdf commented Jan 24, 2012

I'd prefer to keep it...

Contributor

philsturgeon commented Jan 24, 2012

Hypothetically speaking, if the cart WERE removed and put in a Spark, and sparks were integrated, then of course the Spark and the Sparks website in general will be fully documented. Please don't consider that as part of the decision, this is about code separation.

If you have an application already using the Cart library this still changes nothing, you'd just grab the spark when you upgrade to 3.0. Not an issue there either :)

Just to play the devil's advocate, what's the main reason of moving Cart to Spark ?

Contributor

joelcox commented Jan 24, 2012

The cart library has a verify specific purpose. It's too specifc to include it in a general purpose framework. Most CI users rarely use it and it only bloats the core.

The cart library has a verify specific purpose. It's too specifc to include it in a general purpose framework. Most CI users rarely use it and it only bloats the core.

Yes is very specific.

Contributor

philsturgeon commented Jan 24, 2012

Let's not ask why it should be moved, but the real question is: "What belongs in the framework".

"Our goal for CodeIgniter is maximum performance, capability, and flexibility in the smallest, lightest possible package."

Where does it say anything in there about including random classes that 10% of people might need?

Now, while I could try using the "I've never used it and plenty of others havent either" argument I'd run the risk of flagging up" "Well I never use XML-RPC either!". This is an argument I've heard back but is still not a great one. Things like the XML-RPC framework help you implement web technologies into your application that would otherwise be rather complicated. This is an abstraction that makes sense.

However, as much as I love the bearded canadian Derek Allard, I don't feel this library has any place in CodeIgniter because it doesn't hit any of the targets for goals.

The whole reason Sparks exist is so the core can be kept lightweight and free of bloat, so a spark can simply be installed to add any extra functionality.

If you ARE building a website with a shopping cart, would asking you to install a Spark in a major upgrade (to v3.0 for example) be a an issue? If so, why?

Great post and ideology for CI Phil. Cheers.

Contributor

colonelchlorine commented Jan 25, 2012

I couldn't agree more with this proposition. Of all the libraries that could be bundled with CI .... a cart makes the least sense. I would rather see an auth library in there before a cart for heaven's sakes.

I <3 XML-RPC

Contributor

philsturgeon commented Sep 19, 2012

Hey @alexbilbie @narfbg can you guys chase this one up now? I should have made this my last act "in power" before I quit :p

Contributor

narfbg commented Sep 19, 2012

@philsturgeon Sorry, but I'm not really familiar with neither of the cart library and Sparks. I'd be happy to get rid of it though. :)

Contributor

alexbilbie commented Sep 19, 2012

I never liked how it worked so I always rolled my own library.

I'll move it into a Spark

On 19 Sep 2012, at 10:29, Andrey Andreev notifications@github.com wrote:

@philsturgeon Sorry, but I'm not really familiar with neither of the cart library and Sparks. I'd be happy to get rid of it though. :)


Reply to this email directly or view it on GitHub.

It's always been one of the dumbest additions to CI.

While I'm not in favour of ORM in CI, it makes me chuckle that the debate has always been ORM is too specific. Then the cart library got thrown in....

Contributor

philsturgeon commented Sep 21, 2012

The Cart library went in before Reactor types had any input. It also existed before Sparks, and Derek A probably didn't feel that shoving it in the Wiki would have been any help.

So, it DID kinda make sense at the time, but doesn't now - which is why it should be moved out. Simple.

Phil Sturgeon

On Friday, 21 September 2012 at 14:16, Paul Rose wrote:

It's always been one of the dumbest additions to CI.
While I'm not in favour of ORM in CI, it makes me chuckle that the debate has always been ORM is too specific. Then the cart library got thrown in....


Reply to this email directly or view it on GitHub (EllisLab#214 (comment)).

Dentxinho pushed a commit to Dentxinho/CodeIgniter that referenced this issue Sep 28, 2012

Contributor

ivantcholakov commented Nov 23, 2012

Please, don't kill the cart.

Contributor

narfbg commented Nov 23, 2012

It would be "killed" in terms of not being included in the default CodeIgniter package, but not completely erased. You'd still be able to get it from a package repository.

Well, as we can see, CI 3 will come with composer, so... goodbye, so long farewell, sparks! The king is dead! Long live the king!

@hfittipaldi Can you direct me to documentation about Composer? I never moved away from CodeIgniter 1.7.x, so I haven't yet used Sparks, but the idea was definitely intriguing and a cool name to boot. Does Composer replace Sparks? Point me in the right direction.... thanks. :)

Ah, Google to the rescue, of course...
http://philsturgeon.co.uk/blog/2012/05/composer-with-codeigniter

Contributor

philsturgeon commented Jan 12, 2013

There is no talk of putting anything to do with Composer into 3.0 at all sadly. Sparks hasn't even made it in, and they would be two contradictory systems anyway.

Phil Sturgeon

On Friday, 11 January 2013 at 20:10, The Digital Orchard wrote:

@hfittipaldi (https://github.com/hfittipaldi) Can you direct me to documentation about Composer? I never moved away from CodeIgniter 1.7.x, so I haven't yet used Sparks, but the idea was definitely intriguing and a cool name to boot. Does Composer replace Sparks? Point me in the right direction.... thanks. :)


Reply to this email directly or view it on GitHub (EllisLab#214 (comment)).

Contributor

cryode commented Jan 12, 2013

Package dependency is still a relatively new thing for me, but I've always felt the cart library was too specific for CodeIgniter. It's rudimentary, too - any serious shopping cart application would need far beyond a single library to incorporate proper functionality. If it was removed, I wouldn't blink twice.

Contributor

narfbg commented Jul 11, 2014

I had no interest in Sparks at all and Composer has taken over that role anyway.

We'll see what we do with CI_Cart, but it will stay in CI3 at least, so I'm closing this now.

@narfbg narfbg closed this Jul 11, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment