MODxCart - (split from shopX)

Quote from: redman at Feb 03, 2007, 11:42 AM

@pixelchutes - it seems a shame not to use xPDO for the db stuff, especially if the new core is using it..?

A shame yes. In fact, without adopting xPDO, this component will not be able to take advantage of the future MODx framework’s one-click installation and migration features (or the mechanism for easily creating installation or migration packages), ability to be quickly and easily ported to other db platforms, db result set caching, JSON caching for the AJAX layer, etc. And I’m definitely hesitant about introducing a component associated with the official MODx brand that does not take these features into account at this point.

But ultimately, all I can do is offer the code and vision, and hope that others see the benefits and choose to adopt it. But this is a common problem in the PHP world and is why there are so many different applications, frameworks and core extensions in PHP that all do the same thing. In particular, the Java community has been very impressive in the ability to define common API’s for common problems that any number of vendors can then offer their own implementation of. I think this is also why the PHP world is often not taken as seriously as Java, and some other enterprise-accepted development platforms. It’s an ad hoc kind of culture that has not yet realized the real value of object-orientation and design patterns at the same level other paradigms have.

Now, I’m not suggesting we have to solve the PHP world’s problem, but we can at least work towards strong community standards within the MODx ecosystem. But it’s going to take a strong commitment to the project by contributors, and a strong commitment to collaboration between the contributors to make that happen.

@redman,

Slick list. Looks like you’ve covered most (and then some!) of the long-term goals I agree are necessities for a shop admin GUI, etc.

As for the xPDO issue, here’s the scoop: Site I’m specifically creating this for is on a shared host, with PDO enabled, but WILL NOT enable MySQL drivers. Therefore, I cannot run emulated PDO, since PHP loads actual PDO runtime... So, a few options come to mind:

1. Change hosts (dedicated/VPS), or continue to push for host to either completely disable PDO, or add MySQL drivers (as client as already paid for the host (per my recommendation), this likely will not happen given time frame)

2. Use shopX. I could attempt using shopX for the small site, and then work on developing MODxCart locally (w/ xPDO) However, I fear the client’s desires with the cart are above and beyond the current state of shopX, and building out some of the functionality could be more difficult/time consuming in the long run.

3. Plan for xPDO conversion. I, by no means, am an xPDO professional. I’ve toyed with, am impressed by it, and believe in it--but I am still learning. Through shared group knowledge/ideas, I believe we can manifest a powerful shopping cart solution for MODx; however, there MAY be some benefits to developing standalone, and in later revisions work on improvements/efficiencies through phasing in xPDO and other features. (like that of MODx 0.9.7)

I guess my point is that xPDO is definitely still on the radar, it has been from the beginning. I fully support its implementation, regardless of what stage that may be.

On another note:

I think some other ideas for the list could be:

- Email management interface: Ability to alter email content/placeholders for various shopping cart events.
(e.g. onRegister, onLogin, onRequestPassword, onCheckoutComplete, etc, etc.)

- Regarding coupons/promotions, the specific ability to use MORE THAN 1 at a time, and possibly to limit the amount of active coupons.

- so much more! LoL

Quote from: pixelchutes at Feb 03, 2007, 12:23 PM

As for the xPDO issue, here’s the scoop: Site I’m specifically creating this for is on a shared host, with PDO enabled, but WILL NOT enable MySQL drivers. Therefore, I cannot run emulated PDO, since PHP loads actual PDO runtime... So, a few options come to mind:

1. Change hosts (dedicated/VPS), or continue to push for host to either completely disable PDO, or add MySQL drivers (as client as already paid for the host (per my recommendation), this likely will not happen given time frame)

2. Use shopX. I could attempt using shopX for the small site, and then work on developing MODxCart locally (w/ xPDO) However, I fear the client’s desires with the cart are above and beyond the current state of shopX, and building out some of the functionality could be more difficult/time consuming in the long run.

3. Plan for xPDO conversion. I, by no means, am an xPDO professional. I’ve toyed with, am impressed by it, and believe in it--but I am still learning. Through shared group knowledge/ideas, I believe we can manifest a powerful shopping cart solution for MODx; however, there MAY be some benefits to developing standalone, and in later revisions work on improvements/efficiencies through phasing in xPDO and other features. (like that of MODx 0.9.7)

I guess my point is that xPDO is definitely still on the radar, it has been from the beginning. I fully support its implementation, regardless of what stage that may be.

1. I’d be glad to post some information about why you should avoid hosts that offer MySQL and have PDO enabled without the MySQL drivers. This host apparently knows very little about the state of PHP, and a few posts exposing this issue may push them into action. And in the meantime, there are ways we can manipulate the xPDO code to work in this situation; we just have to fool it by changing some class names for this specific case...i.e. we can find a working solution in this currently problematic environment. The other benefits from xPDO will more than make up for the time spent figuring this out and/or dealing with the host.

2. We can certainly start with shopX, but why not look at something robust, like say osCommerce, which I have already reverse engineered using xPDO. In fact, someone is using it to render the entire front-end to their osCommerce installation using only the xPDO model and Smarty templates. We could easily take this model, refactor it to better fit as a native add-on to MODx (i.e. user accounts, permissions, produce admin interfaces), and quickly realize a much more robust model, potentially being able to reuse the vast knowledge and some of the contributions available for that project...

3. Converting something to xPDO is perfectly valid as well. Same process as reverse-engineering osCommerce. The benefit of doing it in xPDO originally is the ability to generate all the code you need to interact with the database in seconds once you have designed a model. With this scaffolding in place, it’s just a matter of writing a few advanced functions on the generated classes for more complex data queries, reporting, admin, etc. We’re talking about saving days, possibly weeks of coding time by taking advantage of this tool...

I’m presently in the planning process to also make my own cart based of Modx since the Shop-X snippit couldn’t fill my two primary problems using the Modx document table ( a large amount of products 5000-10000 and the need to manage 2 languages)

I’m interested in ether helping with the development of a ModX cart or getting input from a current project as to avoid having many people working on the same thing.

On a side note, since it’s looking that I will have to use a separate database for my cart what would be the best way to integrate it with ModX so that I can use ModX facilities such as friendly URL or other snippits with my cart ?

(Sorry if there are any spelling errors but English is not my first language)

Make a module to manage your separate table, then access it from a snippet as you would any of the MODx tables. See my tutorial on managing a table from a module on my sottwell.com site; use the guest Manager login to see how it works.

You could also create an admin module to expand the original doc tree, joining on doc ID... in other words, create a foreign key (doc id) to incorporate additional/advanced attributes at the document level.

I’m eager to get modX eCommerce working too!

We would primarily use it for smaller shops. I see a fully featured cart ala osCommerce or X-Cart as being a long haul.

Also, the Feature List starts to get bloated.

I concur with Ryan, in that I’d like to see the pages used to display the products, as that gives a lot of flexibility; and keeps the templating work unified.

A GUI for Admin is essential.

I’d be happy to do testing. We are also interested in contributing development time; but not sure at this stage if our requirements would be better pursued via ShopX which seems to have less expansive goals.

Richard

Thanks rciardsanX. After the next release I hope to turn my attention more focused to this matter (around the new core actually ... which should be publicly previewed at the same time as the next release ... and it’s a major game changer).

I know...FYI, I have chosen the ShopX route per time constraints so that this eCommerce solution is not rushed in any way. Also, per xPDO, I wish to develop under 0.9.7 SVN+ to reduce any kind of rework, etc.

While I agree, an ever growing feature list sounds nice, but I practice the philosophy of "Release early, Release often"

I think a few crucial shopping cart features should be slated for a Phase 1 release, working towards the more advanced features once sufficient UAT has occurred confirming the first release is even stable--then move on to the big boys.

Exactly pixelchutes... basically a cleaned up easy to set up version of what’s in shopX today would be a great start. In fact, Zap and I have already started cleaning up the framework for credit card processing, and have a better testing and debug reporting done (echo-inc code will be freely usable for starters).

Next up should be the cart stuff and converting the multi-page checkout to a multi-page (standard) eForm I think.