To follow up, I think your idea of a base class is a really good one. I'm going to actually try something similar:
1) Create a new BaseProcessor and update the existing Tax Processors to inherit from it 2) Include a new by_product_and_price method in BaseProcessor, which defaults to simply calling by_price 3) In locations where by_price is currently called but product data is available, change the calls to by_product_and_price This likely could be accepted into Satchmo trunk without any disruption of existing sites. Then I can just write a custom processor that inherits from tax.modules.area and overrides the by_product_and_price method and the _get_location method. On Mar 18, 4:31 pm, Nan <[email protected]> wrote: > > You can create many tax classes (several for every area) if one area > > is bind to the product (us-high us-low uk-high uk-low uk-...) and > > create a model for your tax processor with the necessary data. The > > area part of the taxclass can be eventually automatically filled by a > > custom Widget for Admin and pre_save signal of your product. > > With products in almost every US state, we'd need a Tax Class for > every product class in every state PLUS a Tax Rate for each Tax Class > for each state, AFAICT. It's just too confusing, when the tax > processor itself should be able to simply select the Tax Rate based on > an attribute of the product. Then we can have just a few tax classes > (e.g. virtual goods, clothing, other), and a tax rate for each of > those for each state. > > > What is "Product Area"? (You sell houses?) It does ot matter. I think > > it is not much typical requirement. How to say, that something is > > unused in a toolbox by users? > > Yes, it's rare, but real estate is probably similar. We sell tourism > products, and have been advised that each product needs to be taxed > according to the location it relates to. > > > > > More desiderable for Satchmo community I consider first to simplify: > > > - create a class BaseProcessor(object): > > # which defines relations between derived methods and the method > > by_price which is the only by_* which shold be defined by every > > descendant class Processor(BaseProcessor) > > def by_price(self, taxclass, price): > > raise NotImplementedError() > > # This can simplify the code without breaking the compatibility > > and it would be easier to create a new tax module. > > One class can be easier documented. Descendants need not it. You are > > right, the name by_price is not inuitive > > > - a documented example module with more functionality than 'no' or > > 'percent' and simpler than 'area' or 'us_sst', with less database > > queries. > > > 'by_product' can be defined by 'by_price', but not viceversa. > > The trouble is that (a) by_price doesn't receive any data about the > product other than its tax class and a price; and (b) calls to > by_price are *hard-coded* into a lot of places in Satchmo where > by_product would be equally appropriate. > > I need a way to pass the product to the tax processor, and the only > way for me to do that is to call by_product instead of by_price. > Working around this without patching Satchmo itself would basically > mean copy-pasting a quarter of satchmo's code, replacing single method > calls in a couple dozen places, and then finding awkward ways to hook > it in. > > In the tax processors distributed with Satchmo, by_product simply > calculates the price and then calls by_price. So patching Satchmo to > change those calls shouldn't mean any disruption to people using those > processors. -- You received this message because you are subscribed to the Google Groups "Satchmo users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/satchmo-users?hl=en.
