Is the Cart.php library a sign that more libraries are coming?

[eluser]Unknown[/eluser]
Our eCommerce company Cularis was considering porting over our eCommerce application to Code Igniter and open-sourcing the application for the CI community.

However, we do not want to create a project that competes in any way with Code Igniter, Ellis Labs or EE. If it does not conflict in any way with current CI development efforts, would the CI community be open to our CI-based eCommerce application?

[eluser]ray73864[/eluser]
you bet, so long as it is fully customisable, the problem i was having with other ecommerce apps is that none of them fit with how the database needs to be structured and all were overly complicated for altering.

[eluser]brianw1975[/eluser]
[quote author="Dan Warner" date="1234921824"]Our eCommerce company Cularis was considering porting over our eCommerce application to Code Igniter and open-sourcing the application for the CI community.

However, we do not want to create a project that competes in any way with Code Igniter, Ellis Labs or EE. If it does not conflict in any way with current CI development efforts, would the CI community be open to our CI-based eCommerce application?[/quote]


I would definitely be interested in something like that.

[eluser]johnwbaxter[/eluser]
@Dan Warner - Competition is good and wider exposure for CI is good. No-one would have a problem with you doing that, it should be positively encouraged.

[eluser]Colin Williams[/eluser]
A cart library has been in the winds for a long time. I think it's a good addition to the framework. And I don't think it bloats the codebase in any negative way. Like any CI lib, you aren't forced to load the file. I also think it serves as a good example for how libraries should be developed. Don't know if that was a goal or not. I think they just saw it as a useful tool to provide for CIers.

Although, I bet something like User Auth would be more readily received, and rejoiced by this community.

[eluser]xwero[/eluser]
[quote author="Adam Griffiths" date="1234921595"][quote author="xwero" date="1234898929"]It seems the marriage of CI and EE is coming closer and this raises the question, where will CI stop and takes the EE core over?[/quote]

I think the whole point of building EE 2 with CI is that CI takes over the core.[/quote]
I you ever looked at the EE site you had seen EE comes in core (free) and full (buy) version.

If CI gets all the libraries, helpers, plugins then i assume already created models, controllers and sql schemes separates the EE core version from CI. Or will there be framework parts for EE only?

[eluser]Adam Griffiths[/eluser]
[quote author="xwero" date="1234934608"][quote author="Adam Griffiths" date="1234921595"][quote author="xwero" date="1234898929"]It seems the marriage of CI and EE is coming closer and this raises the question, where will CI stop and takes the EE core over?[/quote]

I think the whole point of building EE 2 with CI is that CI takes over the core.[/quote]
I you ever looked at the EE site you had seen EE comes in core (free) and full (buy) version.

If CI gets all the libraries, helpers, plugins then i assume already created models, controllers and sql schemes separates the EE core version from CI. Or will there be framework parts for EE only?[/quote]

Ah, good point. I thought you meant...well, I think you know what I meant.

[eluser]Colin Williams[/eluser]

If CI gets all the libraries, helpers, plugins then i assume already created models, controllers and sql schemes separates the EE core version from CI. Or will there be framework parts for EE only?

EllisLab has always given the vibe that EE on CI will be a very tightly coupled application, not something that can be used piecemeal. I think they abstract functionality out to a CI library only when it makes sense to do so. The mantra is still, "If EE needs it, CI gets it." Of course they draw lines as they see fit, but I don't think we'll see a bunch of libs that only benefit EE.

I think Cart might signal some shift in their practice though. I think they might be more focused on the concept of overloading libraries because Cart looks like a good interface/abstract class-like base for a more customized cart class. It's also the first official library that really blurs the line between model and library (just look at the API: insert(), update(), contents(), total_items(), etc). Maybe more light-weight, abstract-like classes are in the pipeline

[eluser]Tom Schlick[/eluser]
they can throw in as many libs as they want ill welcome every one of them. even if you dont use them they give you ideas on how to better structure your code / implement a feature. plus if you do use them they save you a lot of time

[eluser]Colin Williams[/eluser]

even if you dont use them they give you ideas on how to better structure your code

That's what I was hinting at in a much more rambunctious manner If this isn't something they consider, it should be. The idea of a bunch of small, helpful libraries makes sense to me. So yeah, I welcome it too.