Jason,
At this point, as you know, the system simply doesn't do this. Which present me with two issues, because I believe the system should do it out of the box.
First, as a developer, I want to work this into a design which meets distribution standards (ie, it works consistently for everyone, and operates in accordance with standard business practices).
Second, you have a client with a need, using a somewhat different software distribution than my target package, who needs a solution within a desired time frame. I would like to help you do that - EOS is not so different yet that this can not be done.
So, bear with me please, as I throw out a review of some of the issues here.
Big issue we're faced with up front is that the discount coupons are not cleanly modularized. The box placed on the checkout payment page serves both coupons and gift vouchers. So, the order total system is taking the single input and processing it for two different systems. Breached modularity.
This is different from payment and shipping modules in at least two ways. First, each set of inputs for a payment or shipping methods is actually generated in the payment or shipping module - not the payment or shipping classes. What these classes do is collate HTML created by multiple modules and outputs it to the page with handling on the succeeding pages similarly separated with the presumption that only one module will be used at a time.
The second is that each set of inputs from payment and shipping modules applies to one and only one module.
These differences should not exist. We will look at what is necessary to more completely modularize coupons a bit later.
The inputs are similar in that multiple inputs are not accepted for any payment or shipping module. Each selector supports one input.
Here is where a problem exists. Credit or discount designators require more. The fundamental nature of the systems is different and their inputs should support the different functionality. What is needed is a multi-selection capability, which introduces issues of its own.
Reloading the page to capture succeeding inputs for a multi-select may clear input provided on other form elements if the shipping and payment modules do not check for the presence of their data and present it as the default content in order to avoid customer frustration and reduce cart abandonment. Every one of those modules should be checked and modified to do so when necessary for the software to be considered distribution grade.
Depend on Javascript to avoid reloads you say? Sure, that can be used to boost performance, and likely should be. But not as the primary execution path. A small but finite percentage of users routinely keep javascript turned off - but the real issue is that people who read code can be counted on to turn javascript off and manipulate the system to their advantage in cases where the code is utterly Javascript dependent. AJAX? sexy stuff, but it puts a load on the clients machine, the state of which is unknown to the server. In any case, it would be best applied after a greater state of object orientation has been attained, when it can be done in an organized, balanced and limited fashion.
The gift voucher system input needs to be maintained. Replacing the coupon inputs with a multi section element will require us to add a separate input for gift vouchers. Not popular with the community - but a necessary design element. Compensate by making the code which generates each input conditional, allowing them to be deactivated from the admin. It follows then that each system should use conditional tests similar to those found in each payment and shipping module which prevent execution if the system is not in use.
Your basic issue touches on a wide community need - the need to build different types of coupons which can mimic the simple paper coupons traditionally used in brick and mortar operations. There is a foundation for this in our new data design, and we further that by adding the includes/plugins directory, and placing the coupon folder within it to hold the new coupon plugins.
Why plugins and not modules? Well, coupon specific code modules should not interact with the user interface at the same level as payment and shipping modules. They need an intermediary to manage them in an way that allows extension. Different code management calls for a different identifier. The plugin id works.
A lot of this has probably been stating the obvious, but I find that a good place to start if you want to catch all the issues and render tightly formed code systems.
Comments?
Home
Help
Search
Login
Register
Print