[Project] shopX 2.1

RE: Doc Vs DB

I think based on what I have read about flexibility that it would be ideal to create the DB Shop Manager as an addon vs. the primary solution. Even as the Cart project grows, there will always be small sites where a doc based catalogue is best and a DB might be overkill. It still may be a good idea to save the configs in a Db table though. But like many sites I have built in PHP you can just as easily use Constants or Variables to do the trick.

ATB,

Jay

Other advantages for using documents for the products:

- you can template the individual product pages
- you can add your own TVs to individual products
- you can add google analytics to each product to evalulate store performance in detail

These are great points! I think though you could record template selection and TVs via the Manager. I am pretty sure since the pages would have to be dynamically generated with unique identifiers GA should work just fine. That being said, the doc method seems to be a nice, easy system that wouldn’t hold back the advancement of the cart system for MODx and, in light of potential Core changes it makes the most sense until 1.0 is in Beta.

ATB,
Jay

Having now read ajayre’s earlier comments:

Yes. Absolutely. To expand this further: Everything should be modularised, even "display price", which may need to pull the ex-tax price, check the tax-band and display it with tax (UK B2C is usually displayed inc-VAT, UK B2B is usually displayed ex-VAT). Then everywhere that there is a price, it uses that function. Or, it may need to check the special offers, and display a strike-through 12.99 and a highlighted 7.99. All extra features need to plug in somewhere; yeah sure this stage shouldn’t be collecting feature-requests but they need to be allowed for.

This all means that although there is more that can be configured, everything only needs to be configured in one location and then all add-ons can use these common functions. The left and right-hand column boxes in osC like random recent product, top 10 lists etc could each be a snippet that can be used anywhere on a MODx site, but they would pick up the ShopX settings and format data the same way as the rest of the site.

I expect that it is worth looking deeply at what MODx 1.0 allows us to do.

doc vs db

Of course, documents *are* in the db. So here we definitely need to consider MODx 1.0, as that appears to let us define a ’product’ type of document and thus gives us the best of both worlds.

Really, I’d like to see ShopX be flexible as to where the product ID and various fields are coming from; it should be possible to abstract things so that they could come from either documents or a dedicated table. The majority of the shops I’m involved in have 1,000+ products; a db table would be easier to migrate to. I have one shop with 44 products, and am very tempted to move that one to ShopX.

There’s always going to have to be a strong association between products and documents, and yes templating them individually (or by type) is a plus. I am also very keen to ensure that products have FURLs.

WOW! Look at all that constructive energy a-flowing! This community never ceases to amaze me...

Personally I also favor keeping ShopX as modular as possible, although I think that we could package one or more default installations (digital sales only, PayPay checkout only, multiple payment and shipping methods, etc.) with some sample products and everything set up for folks who don’t need much customization. I actually centralized a lot of the code into one plugin that checks for form input and sets placeholders and variables, and I actually don’t think that this makes the solution any less modular. There would be some sections in this plugin that many people would want to modify or just comment out, but this seemed like the natural place to have all the common code.

I also like the document products model in general, both because it’s a tried-and-true interface that clients understand and because it allows us to make use of the wealth of MODx swiss army knives (Ditto, eForm, etc.) for associated features. But I can imagine that for a 1000-product store that might make for slow menu generation and other performance issues (especially since caching may need to be off for product forms to function), so we may want to consider a table-based alternative as well. Future releases of MODx may negate this downside for very large catalogs, however.

In the current versions of ShopX that I’ve seen the plugin intercepts and processes the form values when a customer adds items to their cart or updates it, so programatically I don’t think it matters at all whether the form that posts the variables was created from products stored as documents or in a separate table (they’re just post vars).

I also think that for most people products as documents will probably work well and be the best method because it allows for easy customization of its values and options via TVs. For example, in the first store I set up with ShopX most products have seven different styles (ranging from pajama to handbag) as well as colors, sizes, etc., and they wanted customers to be able to choose from among all these dynamically with the photos and options updating as they made choices. And the one I’m doing now doesn’t have fixed prices for their items; they have a minimum and maximum price range and we need to let people choose what they want to pay within that range. Neither of these would’ve been possible without TVs, although I guess if a separate product table existed I could’ve modified that and then used TVs to display the data the way I wanted it. MODx’s innate flexibility allowed me to create these totally non-standard stores as if they were any other, and that’s a HUGE advantage over any other cart solution I’m familiar with.

I actually forgot to mention in my post yesterday that I’ll be adding the Google Analytics Goal-tracking code to my thank-you page template this week (which should be a piece of cake to do). And that I still may need to add an inventory control table to one store and I’m currently scratching my head over the best way to do that (mostly so that clients can easily update it every day - they have a lot of offline sales as well). If anyone can tell me how to create a check-box TV based on the values entered into other TVs I can probably avoid having to create a full inventory system for this site and move on to other things...

Quote from: sottwell at Nov 19, 2006, 11:51 PM

Good! I was hoping this would "beat the underbrush" and scare out whoever is working on this thing! Zap, I will gladly yield to you, as well as Scotty. I am over my head on this; it’s just that since I started it I feel sort of responsible for it.

I forgot to mention again that you did one helluva job getting this project going, Susan! I doubt very much that you are actually over your head, so if you have the energy to continue contributing to it (and you never seem to lack energy) then please do. I feel like I learn something every time I look over code that you’ve written, and I’m sure that others have had the same experience.

does this method work with digital downloads... or is this feature a possibility with the current set up?

Quote from: sir_thomas at Nov 20, 2006, 10:50 AM

does this method work with digital downloads... or is this feature a possibility with the current set up?

AFAIK, no one’s done that yet, but it should be a simple addition to the current code (download file name in a TV and a thank you template with code to start the transfer).

The download page has to be protected so someone can’t later revisit the same URL and get the download without paying. So maybe that needs to be tied into the web users system? But then people might share username and password info with others.

Andy

Right. There are lots of ways to do this, so we’ll just have to choose one or two and set them up. Carts that create user accounts could use that info to authenticate the download, and those that don’t can set download approval vars in the plugin and send them via email to the customer as well (and without these vars to authenticate the download the page wouldn’t do anything, so people wouldn’t be able to abuse it).

So which part of that should be in a ShopX framework, which part is already in MODx/other snippets and which part should be user customization? I.e. where is the line drawn?

Andy