Cartridge-Best way to add additonal forms/steps to payment

[Mehmet Özgür Bayhan]

I have some question. I've searched the old mails in this mail list but cant find a proper way.

1) Is there any chance to add additional steps to payment?  (In some cases we may need it)
2) Is field injection  avaliable for cartridge as we've done it in mezzanine?
3-a) If 2 is ok, how may i add these fields in form wizard?
3-b) If 2 is not ok, how may i override Order and Checkout form(by not touching the original cartridge code...)
4) Is there any chance to make discount for grouped elements? For example x is 10$ and y is 15$. I someone buy x and y together total is 13 $.
5) Is there any chance to make discount by quantity. For example 1 X is 15$, but 100 X is 10$ per item

I can do all of these by changing the source but i don't want. Because we may use these for many different sites. So i don't prefer to make a new branch.

Thanks for answers.

[Ken Bolton]

Hi Mehmet,

I am going answer the question you started to ask after your list because that is the one that interests me. How do I, as a developer writing software for a future me to maintain, make changes to default Mezzanine and/or Cartridge? I want to know what others think. I favor monkey-patching. How do you do?

1. Yes.

2. Yes.

3a. There are no wizards, but fields can be added to your custom Admin classes.

3b. Monkey-patching, also read the docs.

4. Not as such, as you'll see from the lack of response on the list, or maybe we are all just clever with our ProductVariations. If you have the need for something special, write it.

5. Ibid.

Search the docs and this mailing list for longer answers to your questions.

ken

--
You received this message because you are subscribed to the Google Groups "Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Mehmet Özgür Bayhan]

Hi Ken. Thanks for your answer.

Monkey patching is a solution but not very clean. Espacially if patches getting bigger and bigger it brings the danger of oversighting.

I have another idea. I am just thinking. Payment steps may be done configurable.I am not talking about configuring the steps of payment.
For example
1) In settings file payment steps setting will be an array as a combination of url and the view function of url. 4 ordinary steps are ready the others can be added by developer.
If someone want to specialize the payment steps (or wanna add another specialized payment step)he may just add an another line in settings like that ('shop/anotherPaymentStep', views.AnotherPaymentStepView), like in urls.py

2) That needs a mechanism for reversing the next steps url and put them in form's action in template for ordinary payment steps.

3) For "additional step"s view functions there can be a session object  so we can call the next step's url just as a standard function of this object
E.g: return render_to_response("mystep.html", {'nextstep': stepContainer.nextstep()}, context_instance=RequestContext(request))

So for most of the cases there is no need for monkey patching, no need for field injection with this kind of solution... I know something is possible something is not or something needs really much effort, so just thinking. It could be good.

About 4. ==>

I think u misunderstand me or something's done different in Turkiye. Most of our customer's waiting this kind of mechanism. It is about selling strategy. It depends selling 2 different items is better than selling 1 type of item.

Here's is an example :

Customer = semi-admin/owner of the site(Our customers)

Item A =  Is tortoise firm's  tshirt. Has 100 in stocks. 50$ per item

Item B = Is another firm's e.g penguin firm's hat. Has 500 in stocks. Normally 10$ per item.

Here is the scenario: B is too much in stocks and the customer want to consume it. So the customer  wants to make a dumping campaign and says if u buy A, it is 50$ , if u buy B, it is 10$, but if u buy A and B together, total is 55$. So when someone want to buy product A he sees the dumping campaign and maybe wanna buy A and B  together. At the end the stocks  decrease 1 per item of A and B .

Anyway. The problem is that. (: I can handle it with workarounds, the thing that i asked is, is there any other proper way wtihout changing anything in code...

Thanks for your concern.

2013/6/19 Ken Bolton <kenb...@gmail.com>

[Ken Bolton]

You can and should do it without changing any code, but you will have to write plenty.

With regard to the problem of what we may call bundled products, you can create custom BundledProduct(Displayable, Priced, RichText, AdminThumbMixin) and BundledProductVariation(Priced) classes. Create a m2m field on the BundledProduct to Product. Write the update_stock methods on BundledProductVariation so it updates the stock of the related ProductVariation. This is real "back-of-the-napkin", but you get the idea. There are certainly other ways to approach this.

hth,

ken