Any insight on this from the BVC developers?

From what I have gathered from looking into the source code, changes to several core source files would be needed. Below of is a summary of my preliminary accessment of the "entry" points from the required modifications. If a bv developer or someone who has a little bit more time under their belt with the BVC5 source code (I'm approaching 12 total hours), could chime in if I have overlooked any of the functionality of how the product customer choices work, it would be appreciated.

1. A New base product "customer choice" template would need to be created to handle the properties associated with accessories.
2. The following classes would need to be modified to handle a new type of customer choice.
a. VariantDisplay
b. ModuleController
c. InternalProduct
d. Product
3. A new ProductAccessory Class and any needed related class would need to be created
4. Additional ascx controls would need to be created for Admin/Edit/View
5. The AddToCart button functions for each template type would need to be updated to handle the additional product customer choice.

Again, if anyone familiar with the system, can recognize any place I may have overlooked, it would be appreciated if it was pointed out. Thanks.

Hi Marcus,

I noticed, the quick "plug-in" ability for those choice types. The problem I am seeing is that none of them seem to provide an adequate interface for accessory type additions. Again, I don't have a huge amount of time with the source but in looking into the Template files as well as the base ChoiceAndInputs classes, I did not see anywhere that a custom input/choice/modifier could hook into so that when a customer selects radio button 2, both ProductX and ProductRadioButton2 should both be added to the cart.

Modifiers seem to be able to change a product, but it would get added to the cart as 1 item, modified, and simply deduct from the inventory of that base product.

Choices seem to take an item that may come in various sizes and choose the correct product number from the catalog and add that to the cart as 1 item controlling the inventory of the appropriate sized product.

My Accessories concept would basically be a "Cross-Sell" to use BVC5 like terminology. The problem with the cross-sell feature as implemented is that there is no way to separate the type of cross-sell products to make items easier to find for the customer. For example, easiest item I can think of as an example would be a camera. A customer may want a case, an extra battery, a variety of different lenses, memory cards, etc. In BV2004 you'd be able to seperate each type by using a html input to describe the section and then create a product accessory checkbox list to handle the accessories for the "heading" and repeat for each additional section. Besides being more organized, it also allowed a customer to add several accessories to the cart with the main product in a single add to cart click, thereby helping the cross-sell complete. The current process of add, back to accessory list, add, back to accessory list, repeat until done, is much less user friendly.

Also, the interface is more difficult for the consumer in the case of an extended warranty. For example, in the cross-sell section they see 3 extended warranties and have to add the product themselves separately, whereas in the current BV2004 implementation using the Radio Button Accessory option, they either select None (with the Is Null Property), 3 Year, or 5 Year. Easier on the customer makes it a much easier sell.

Again, if I am overlooking something in the implementation of those "customer choices" that would allow the functionality I am looking for with the creation of simple /admin/edit/view controls and overriding the appropriate methods, I would be all for it. But in looking at your Checkbox Input, it appears that it is nothing more than a wrapper of sorts for a text input of Yes and No.

What I will say, is in thinking about this, it appears that a better way to implement my solution may be using the Cross-Sell classes as a starting point rather than the input classes.

Any further comments are appreciated.

BVUser,

The core of BV Commerce 5 supports many plugin areas including product choices, product modifiers, product inputs, product page templates, category page templates, shipping methods, payment methods, content blocks and more.

Saying that something doesn't support "easy" expansion is meaningless because the developer's skill set determines what is "easy." Flying a 747 is easy for a guy that has 30 years of experience but it wouldn't be so "easy" for me. That doesn't mean that 747's are hard to fly just that it's easier if you know what you're doing.

I believe it would be possible to create a product modifier plugin that adds products as accessories. I also believe that you could create a product page template plugin with custom logic and display if the first option is too difficult. Neither of these require changes to the core code.

Hi Marcus,

You last post appears to indicate I am severely overlooking something in the core logic of product modifiers.

First off, I understood your post to indicate that you feel it is possible to create a plug-in simply by creating a new modifier directory and custom coding the required View/Edit/AdminView control files with no additional changes to the product templates, etc for the plug-in to work.

Assuming that, I do not see how that is possible. I previously incorrectly used the term "core" when my intention when that it was not possible via a standard plug-in meaning a simple addition of View/Edit/AdminView Controls for the item.

My reasoning for this is there is nothing in the code for the AddToCart button, VariantsDisplay, etc to properly handle adding additional items to the shopping cart. The VariantsDisplay, WriteValuesToLineItem function relies on GetValue functions to add input or modifier information to the specific LineItem of a product. It does not create a new lineitem as would be needed to create a product accessory modifier. The AddToCart button in turn relies on the VariantsDisplay for its information about the currently choosen product "Customer Choices" (used to collectively mean input, choices, and modifiers).

With that said, I do agree that there is a way to create product accessory modifiers or in looking at the code, I think they would be more efficiently handled as an input, by modifying controls outside of the core to handle the specific product input requirements.

If my logic is off and you still know of a way to create a plug-in without modifying these external controls, I'd be willing to pay for consulting time as to how exactly you see am implementation working.