Part 5 of my blog series on integer-net.com about framework independent code is out: Using Advanced Autoloading. This one is only relevant for the integration of legacy applications that do not use composer autoloading yet (Magento 1).
Design Patterns for Framework Agnostic Extensions/Plugins – View Model
Part 4 of my blog series on integer-net.com about framework independent code is out: Preparing Data For Output
Previous parts
Design Patterns for Framework Agnostic Extensions/Plugins – Bridge
Part 3 of my blog series on integer-net.com about framework independent code is out: Building Bridges
Previous parts
Design Patterns for Framework Agnostic Extensions/Plugins – Dependency Injection
Part 2 of my blog series on integer-net.com about framework independent code is out: Using Dependency Injection
Previous parts
Design Patterns for Framework Agnostic Extensions/Plugins
My new article series on integer-net.com introduces useful design patterns for decoupled Magento extensions, which are divided in two parts: the Magento module and a framework independent (framework agnostic) library, that is reusable for Magento 1 and Magento 2. Of course, the same principles can also be applied to other frameworks and applications.
It will not cover the refactoring process from existing extensions to this model, that’s a different topic and I am going to talk about it at Developers Paradise 2016 in Croatia. Stay tuned!
The first part is about accessing application configuration, using Configuration Value Objects.
Show random products in Magento: You are doing it wrong
Well, probably (I certainly have).
A typical requirement is to show random products on the home page, random products of a category on the category page, or similar. Magento offers a simple block that can show a specified number of random products, Mage_Catalog_Block_Product_List_Random. To add filtering, like by category, you still need to write your own block, but it could easily be extended.
This is the CMS code:
{{block type="catalog/product_list_random" num_products="4"}}
But don’t get too excited. This block type will make your site slow, you should not use it. The problem is in this line:
$collection->getSelect()->order('rand()');
I’ve been recently advocating against using ORDER BY RAND()
to select random products from a Magento database. 1 Generally, this method is discouraged because of its performance issues.
Continue reading “Show random products in Magento: You are doing it wrong”
Notes:
- For example in this Magento StackExchange post: Four Random Products on Homepage ↩
Efficiently Draw Random Elements From Large PHP Array
I recently needed to select few random elements from a big database table and was looking for alternatives to ORDER BY RAND()
(because of its performance issues). Because the IDs are not continuous, the proposed solutions in the linked article are not sufficient.
So the idea is to fetch all IDs from the table, pick X random IDs and query these directly. The memory overhead of reading an array of about 100,000 IDs is not too big, so the problem is reduced to how to pick random IDs efficiently with PHP.
Continue reading “Efficiently Draw Random Elements From Large PHP Array”
Comparable Interface For PHP
About 5-6 years ago I had my “PHP should be more like Java” phase and experimented a lot with things like string objects and method overloading, which usually required hackish workarounds and most things did not turn out to be very practical in the long run.
But there is one package I still like very much, namely ComparatorTools, which got to be place 2 in the monthly PHPclasses.org innovation awards after all. It provides Comparable
and Comparator
interfaces and functions similar to the core array functions, that can work with these.
Interfaces
The interfaces resemble the corresponding Java interfaces, except that we do not have Generics in PHP, so it is cannot be guaranteed that compared objects have the same type. This has to be checked at runtime in the implementation, if needed. An exception type for these cases is provided:
interface Comparable { /** * @param object $object * @return numeric negative value if $this < $object, positive if $this > $object, 0 otherwise (if objects are considered equal) * @throws ComparatorException if objects are not comparable to each other */ public function compareTo($object); }
interface Comparator { /** * @param object $object1 * @param object $object2 * @return numeric Negative value if $object1 < $object2, positive if $object1 > $object2, 0 otherwise * @throws ComparatorException if objects are not comparable to each other */ public function compare($object1, $object2); }
CSV Processing In Magento
A development principle , not only with Magento, is that you shouldn’t try to reinvent the wheel and especially use the functions of the used framework wherever possible. Magento has many more or less known universal helpers, in the helper classes in Mage_Core as well as in lib/Varien and of course in the Zend Framework.
A classic is for example JSON encoding. Although PHP has its built-in functions json_encode and json_decode, but they have some shortcomings that are compensated for in the Zend_Json implementation. So Zend_Json::encode()
has a cycle check, Magento added support for inline translations within JSON strings in Mage_Core_Helper_Data::jsonEncode()
. Thus in Magento you always should use Mage::helper('core')->jsonEncode()
(and jsonDecode).
Varien_File_Csv
How is it with processing CSV files? Since import and export works with CSV files in the standard implementation, Magento should have somthing, right? Presenting Varien_File_Csv
! Well, I’ll anticipate the result: except for very simple tasks with small files, the class is not useful at all.
A JSON-RPC Adapter For The Magento API
Going through my old answers on Magento StackExchange, I found this question about using the Magento API via JavaScript and noticed that the link to GitHub that contained an important part of the solution, namely implementing a JSON-RPC adapter for the Magento-API is dead now.
So I decided to publish my complete module myself (the original link was a core hack, I rewrote it as a clean module):
The whole module is less than 100 lines of code. In config.xml
our controller is added to the api
route:
<frontend> <routers> <api> <args> <modules> <sgh_jsonrpc before="Mage_Api">SGH_JsonRpc_Api</sgh_jsonrpc> </modules> </args> </api> </routers> </frontend>
The new API adapter is defined in api.xml
: