We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 14050
    • 788 Posts
    Quote from: pixelchutes at Feb 02, 2007, 11:21 PM

    All--

    With session management a requirement for my cart, there can be pros/cons as to the chosen implementation... I’m interested to hear your opinions, so I’ll be quick:

    Snippet, Plugin, or Both

    I’m envisioning a Module for the Admin GUI, and possibly a Plugin for session management. Plugin could also listen for a token, and handle all of the shopping cart needs, as far as server side processing is concerned.

    Snippets could be used for placing the Cart/Checkout html ...also with chunk/doc_id expansion options

    Thoughts?

    I would imagine both. I also envisioned a module for the Admin GUI. I think the snippets would be nice for instances like adding payment gateways (a gateway for each snippet), shipping options, etc.
      Jesse R.
      Consider trying something new and extraordinary.
      Illinois Wine

      Have you considered donating to MODx lately?
      Donate now. Every contribution helps.
    • Quote from: jesster444 at Feb 02, 2007, 11:26 PM


      I would imagine both. I also envisioned a module for the Admin GUI. I think the snippets would be nice for instances like adding payment gateways (a gateway for each snippet), shipping options, etc.

      Nice!

      How do you envision snippets being used to Add payment gateways?

      I was thinking snippet usage something like:

      [!MODxCart? &action=`listCheckout` !]
      
      [!MODxCart? &action=`showCart` !]
      


      (these are just examples)
        Mike Reid - www.pixelchutes.com
        MODx Ambassador / Contributor
        [Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
        ________________________________
        Where every pixel matters.
        • 33372
        • 1,611 Posts
        I’m wondering the same thing as Ryan: What is fundamentally different about the cart that you’d like to develop that would keep you from using ShopX as your base?

        It’s great that y’all have energy to work on this, especially since I for one haven’t been able to dedicate much time to ShopX for a while now. I will set up a test install of ShopX as I’ve been using it and give access to interested folks who PM me. Personally I think that if you look at ShopX you’ll find that a) it’s very modular, so you could probably do whatever it is that you think you need to do differently without starting over from scratch, and b) a lot of the fundamental questions about processing and whatnot have already been worked out in at least one way that works.

        You will also immediately realize that c) there’s still a lot more to do and a lot about ShopX that needs improving, but it is a functioning MODx-native shopping cart system, so it seems like a good place to start if that’s what you’re after...
          "Things are not what they appear to be; nor are they otherwise." - Buddha

          "Well, gee, Buddha - that wasn't very helpful..." - ZAP

          Useful MODx links: documentation | wiki | forum guidelines | bugs & requests | info you should include with your post | commercial support options
        • You’re absolutely right. I’ve downloaded the ShopX code, and it is an excellent starting point for FREE eCommerce within MODx! The structure/organization of the code was in need of some clean up I thought?? (per one of your previous posts)

          Realistically, our company has some pretty demanding marketing/SEM needs that I want integrated into the core of the Cart System, and again, I would prefer the base code to be a PHP Class, Object Oriented, etc. I plan on building the cart to be scalable--down to its core.

          While the ShopX approach provides modularity and scalability through MODx, I also want the code to be flexible as well. Properly structured cart object with predefined methods/attributes will make this a breeze ( I hope wink )

          I also plan to have an install for this add-on to build out the base MODx structure (modx tree), defined Plugins/Snippets, etc.

          In summary, I’m not looking for a good place to start, ShopX already provided that to me. I’m really looking for an all encompassing opinion as far as feature set/functionality is concerned. Coding has been underway since mid-January
            Mike Reid - www.pixelchutes.com
            MODx Ambassador / Contributor
            [Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
            ________________________________
            Where every pixel matters.
            • 33372
            • 1,611 Posts
            It’s still in need of some clean-up (maybe more since I started messing with it)...

            I have set up a test install of MODx on a server we control, and I will add the ShopX code to it tonight/tomorrow. PM me for access. I need to make some minor changes to it in order to make it function in this environment (since I’ve been using a separate database for order data on live stores with offline processing, but for testing purposes I think it’s better to use the main MODx database instead).

            In the version that I use a lot more is done in the main ShopX plugin than in the original version done by Susan. I don’t use the user account features that Ryan has on his site, so those are not in my trunk of the code at all. I also haven’t set up anything but offline processing sites so far, but Susan’s Echo processing module works perfectly and is a great template for any similar gateway.

            There are a lot of bridges still to cross, including restructuring the checkout process using eForm over multiple pages, improved product option management, inventory control, etc. I use a very simple scripted TV to allow store managers to set specific combinations of options as available or out-of-stock (e.g., red small t-shirts are available, but blue small is out-of-stock). I think that combining this technique with a dynamic (Ajax) option form would be a lot better than refreshing the whole page (as I do now).

            The discussion in the ShopX forum was trending towards coming up with a standardized database structure, classes, etc., and I would think that’s still a first priority for any next-generation shopping cart project.

              "Things are not what they appear to be; nor are they otherwise." - Buddha

              "Well, gee, Buddha - that wasn't very helpful..." - ZAP

              Useful MODx links: documentation | wiki | forum guidelines | bugs & requests | info you should include with your post | commercial support options
            • Oh really? Where are the write ups regarding table structure...I would be interested to see...
                Mike Reid - www.pixelchutes.com
                MODx Ambassador / Contributor
                [Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
                ________________________________
                Where every pixel matters.
                • 33372
                • 1,611 Posts
                There is no proposed unified table structure yet. There are several different versions out there, all variations of Susan’s original code I think. You can see the types of things being proposed if you pick up the conversation around here: http://modxcms.com/forums/index.php/topic,1575.195.html
                  "Things are not what they appear to be; nor are they otherwise." - Buddha

                  "Well, gee, Buddha - that wasn't very helpful..." - ZAP

                  Useful MODx links: documentation | wiki | forum guidelines | bugs & requests | info you should include with your post | commercial support options
                  • 24719
                  • 194 Posts
                  hmm, i’m kind of torn. i like the idea of shopx, but the development seems to have stagnated.

                  as far as doc pages vs db, i’m working on something else that will use both - doc pages to hopefully ease features like searching, displaying listings, etc, and also a db to store data more efficiently than simply as tvs. admins can enter details via eform, which then constructs the content of a document in a standard way, but stores the data in a custom table for simplicity and flexibility. this isn’t for e-commerce though...

                  i haven’t much experience of shopx, but while i can see it would be good for smaller sites, i want something that will scale well and that is more fully featured. one of the most important features for me would be an admin gui. as has already been said, i’d also like chunks/snippets to display the different components. thinking about the gui, none of the e-commerce packages i’ve looked at so far use ajax. there’s so much scope for making a really user friendly gui (pommo does this well) unlike the hideous mess of zencart (which has so many options and features i’ve no idea what they do, and am loathed to give to a client for fear they’ll break it).

                  something i think is critical that was mentioned in the shopx forum is setting up taxation zones. i think a core class could achieve this nicely as was touched upon in the shopx forum - a central class with methods for calculating the price at different stages (pre-shipping, post-shipping, etc), but done in such a way (perhaps through the use of events ala eform) to allow data to be manipulated, or to define custom code for those functions.

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

                  i agree that a feature list should be drawn up to plan this properly. how about we start now with ideas? my wishlist is as follows

                  * ajax gui available either as a module, or able to be inserted into a page as a snippet
                  * being able to define different taxation zones, and multiple zones within a country that could be applied to the same product based on the value of a select box (e.g. in the uk, no vat is applied to children’s clothes, but it is to adult clothes, but no vat would be payable for international orders. for instance, this would make it possible to allow one listing for some generic footwear and have different levels of tax applied to uk customers based on the size that they select),
                  * ability to add multiple payment options/gateways
                  * allow users to register in different ways
                  * stock control (only display in-stock items, or a message if an item is out of stock, or not show it at all if out of stock)
                  * be able to sell digital products securely (so download restrictions could be enforced like number of downloads, expiry date for each user, etc)
                  * ability to define multiple shipping methods

                  (i think this is cube cart pretty much matched)

                  * a default install to get users up and running quickly optionally populated with some sample data
                  * support for attaching media to products, optionally using maxigallery to display images,
                  * auto-thumbnailing and/or image reduction for uploaded images (this could be done most easily by using an existing snippet and eform-style events i think)
                  * order tracking
                  * comprehensive statistics logging
                  * promo code manager for admins to set up promo codes and gift vouchers
                  * allow items to be put on sale easily
                  * configurable options for different products, either by category or individually (e.g. size, colour, etc)
                  * list a product in multiple categories
                  * use FURLs
                  * encrypt user’s data (might be getting carried away now... wink)
                  * quantity discounts
                  * multi language/currency/time-/number-formats, etc
                  * affiliate manager

                  that’s about all i can think of for now. not all of these would be necessary at first, but i think having an ultimate wishilist would encourage coding an extensible system. anyone else have any ideas?
                  • I will say that I agree 100% on building any new ecommerce effort and not using xPDO would be very short sighted.

                    At the same time, I don’t think the effort to clean up what’s in existence is without merit—a cleaned up baseline of shopX to start from wouldn’t really be such a bad thing.

                    Stagnation has happened strictly from the standpoint that we’ve focused on 095 and the next release. More and more of the legacy core has been cleaned up, and you’re seeing the last of the legacy releases barring any unforeseen security updates with the next release. Keep in mind that shopX is pretty much just a proof of concept. (It works, too!)

                    I actually intend to create a "premium channel" in the forums focused on Online Business (encompassing SEO and ecommerce). But for now, I’m off for the rest of the weekend. laugh
                      Ryan Thrash, MODX Co-Founder
                      Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
                      • 24719
                      • 194 Posts
                      i agree we should reuse what is already available as far as possible.