Smart Search плагин не привязанный к базе данных

Joomla! 2.5 интегрировал Расширение средства поиска в его ядро, добавив новую Умную Функциональность поиска. Уже Joomla! документация включает прекрасное учебное руководство для записи Умного Поискового плагина, однако это предполагает интеграцию с Joomla! база данных. С MageBridge мы записали плагин SmartSearch, который интегрируется с удаленным источником (Magento), и мы думали, что это будет хорошая идея совместно использовать это с Вами всеми.

Основная функциональность Умного Поиска

Старый поиск Joomla! полагался на плагины, которые могли немедленно искать в базе данных. Однако функциональность нового Умного поиска, обеспечивает API для индексации вместо этого: Плагины могут все еще поставить содержание, но ядро Умного Поиска определяет, как это содержание индексируется и ищется. Умные Поисковые плагины могут легко быть созданы, расширив класс FinderIndexerAdapter (вместо базового класса по умолчанию JPlugin).

Класс FinderIndexerAdapter делает его очень простым для разработчиков плагинов (см. Joomla! Руководство по документации, Создание плагина Умного Поиска для подробностей): Определите свою собственную таблицу (переменная $table) и переопределите getListQuery () метод. Но это предполагает, что Ваше содержание совместно использовано в таблице в Joomla! база данных. С MageBridge мост (API) вызывают, чтобы запросить приложение Magento удаленно через HTTP, и для этого это учебное руководство не применялось.

Индексация содержания: getContentCount() и getItems()

Таким образом вместо того, чтобы переопределить метод getListQuery() , мы посмотрели в классе FinderIndexerAdapter, какие методы зависят на этого метода. Есть - 3 метода: getContentCount(), getItems() и getItem(). Мы фокусировались на первых двух для начала.

Переопределение getContentCount()

Индексируя содержание, есть 2 способа выбрать содержание во-первых: Выберите все содержание сразу или выберите их в пакетах. Finder-расширение упрощает выборку содержания в пакетах. Чтобы знать, сколько пакетов необходимо во-первых, Вы должны будете сначала узнать, сколько там элементов контента. Метод getContentCount() делает это возможным. Но вместо того, чтобы делать запрос базы данных, Вы могли просто переопределить весь метод, чтобы применить Вашу собственную логику:

protected function getContentCount()
{
    return 10; // replace this with your own logic
}

В нашем случае мы использовали этот метод, чтобы использовать интерфейс MageBridge для Magento, чтобы выбрать общую сумму продуктов. Поскольку для этого еще не было никакого ресурса API, мы создали новый ресурс magebridge_product.count() в приложении Magento.

Переопределение getItems()

Второй метод, который полагается на getListQuery() это getItems(), который возвращает фактические данные для индексирования. Результат возврата должен быть массивом с объектами типа FinderIndexerResult.

protected function getItems($offset, $limit, $sql = null)
{
    return array();
}

В нашем случае мы снова вызвали API Magento для выборки продуктов, преобразования этой выборки в возвращаемый массив. Вместо того, чтобы выбрать все продукты, мы использовали параметры $offset и $limit, чтобы только выбрать определенную страницу набора Magento. В то время как параметр $sql требуется для того, чтобы должным образом переопределить этот метод, его значение не используется в нашей логике - это - фиктивный параметр.

Некоторые причуды

В нашем случае type_id флаг каждого $item не был установлен должным образом - в таблицах Finder Базе данных, это было установлено в 0. Мы для этого явно вызвали метод getTypeId() так, чтобы флаг был установлен:

$item->type_id = $this->getTypeId();

В таблицах Finder Базе данных также упоминается list_price и sale_price. Мы фактически не знаем то, что это для, но - какого черта - мы заполнили эти поля базы данных так или иначе с ценой продукта Magento.

В Joomla! Руководство также упоминает методы translateState(), getUrl() и getStateQuery() - они так же не используются в нашем случае.

Переопределение getItem()

В нашем случае мы еще не переопределяли метод getItem(). Этот метод полезен, когда определенный элемент контента был бы повторно индексирован, например после того, как он был изменен в админке. Это потребовало бы, чтобы событие плагина сначала было вызванно, после этого Finder плагин мог взять на этом событии. Мы пропустили эту часть до сих пор, поскольку будет требоваться большая дополнительная работа:

The Magento backend would need to catch the Magento event catalog_product_save_after. This would need to be picked up by the MageBridge event-listener to forward this event to Joomla!. In Joomla!, the MageBridge-Magento plugin needs to translate this event into a Joomla! event instead (mageCatalogProductSaveAfter), which can then be picked up by the Finder-plugin to reindex that item. The MageBridge API is completely ready for this, but let's focus first on making sure that SmartSearch gets us what we want, right?

Бэкэнд Magento должен был бы поймать событие Magento catalog_product_save_after. Это должно было бы быть взято слушателем события MageBridge, чтобы передать это событие в Joomla!. В Joomla!, плагин MageBridge-Magento должен перевести это событие в Joomla! событие вместо этого (mageCatalogProductSaveAfter), который может тогда быть взят Finder плагином, чтобы повторно индексировать тот элемент. MageBridge API абсолютно готов к этому, но давайте фокусироваться сначала на проверке, что SmartSearch получает нас, что мы хотим, правильно?

Оригинал статьи