Please note, this question is regarding the shipping cost, not price. There is an important difference, i.e. what $$ charge the shipping method incurs for the store owner, as opposed to what is $$ charge is paid by the customer.
The shipping_tablerate
database table includes a cost
field, which is populated in the Mage_Shipping_Model_Carrier_Tablerate
object during the collectRates
method. However, that field is not accessible anywhere else in the stack, e.g. from a quote's address.
I need to access that value on the cart page, and I can't find anyway to achieve it, other than to instantiate a Mage_Shipping_Model_Rate_Request
object to pass into collectRates()
. That seems unnecessarily inefficient given that the data is already loaded from the table and should be accessible.
I have tried Observing the <shipping_carrier_tablerate_load/>
event, but it seems that the _load
event is not thrown for that model.
I have also tried accessing the rate from the quote:
$quote = Mage::getSingleton('checkout/cart')->getQuote();
$address = $quote->getShippingAddress();
$rate = $address->getShippingRateByCode($code ='tablerate_bestway');
I can see the calculated price
, however cost
is not present in that model.
At this stage, I'm running out of ideas. Any suggestions gratefully received!
Thanks, Jonathan
First, try not to worry too much about performance until you see an actual bottleneck somewhere. Have faith in the multitude of caching systems. Put more cynically, Magento's already a bit of a SQL beast, so if you have a store tuned well a few extra queries won't hurt.
Second, the database hit might not even be a problem. The shipping/rate_request
Model doesn't appear to be backed by a database. If you look at the two times it's used in the core code
Mage_Shipping_Model_Shipping::collectRatesByAddress
Mage_Sales_Model_Quote_Address::requestShippingRates
you can see the shipping/rate_request
model is being instantiated, and then populated from already loaded fields. Additionally, all the models used in Mage_Shipping_Model_Carrier_Tablerate::collectRates
don't load anything from a database, they just do calculations.
It's admirable that you want to build something that's as performant as possible in the first go around, but there's too many complex interactions in a modern OO system to magically know the most performant way to do something. Do what you need to to get the information you need, and handle performance tuning (if needed) during a maintenance release (or if you're not lucky enough to have maintenance release, when someone with power in your organization grumbles about the speed somewhere)
Third, when the system doesn't provide access to something yo need, that's what the class override system is for. Something like
class Package_Module_Model_Carriertablerate extends
Mage_Shipping_Model_Carrier_Tablerate
{
public function getRate(Mage_Shipping_Model_Rate_Request $request)
{
$rate = parent::getRate($request);
Mage::register('package_module_carriertablerates', $rate);
return $rate;
}
}
...
//later, retrieve the rate
$rates = Mage::registry('package_module_carriertablerates');
You're basically calling the same code as before, but stowing the results away somewhere for later access. About as safe as an override can get.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With