Я тут придумал новый компонент, рекомендую его внести в стандратную поставку, так как он очень удобен. Вот код компонента:
<?
if(!defined("B_PROLOG_INCLUDED") || B_PROLOG_INCLUDED!==true) die();
$arResult = array();
if($this->StartResultCache())
{
$this->IncludeComponentTemplate();
}
// Примечание: на данный момент код компонента дополнен новыми фукнциями, последняя версия компонента лежит в архиве в конце поста.
?>
Для чего он нужен?
Пример жизненной ситуации: на страницу нужно добавить какой-нибудь простенький функционал, который надо программировать. Но создавать новый компонент (копировать в своё пространство, настраивать путь для дерева компонентов, придумывать название, описание, и тд.) - влом.
Тогда берем такой компонент, кидаем его на страницу, в файле result_modifier.php создаем нужную логику, и пишем свой шаблон. При желании несколько параметров можно вынести в настройки, создав в шаблоне файл .paramters.php.
Плюсы такого компонента: - Находится в стандратном дереве каталогом, доступен на любом сайте; - данные в файле result_modifier.php кешируется; - мы можем написать абсолютно нужную и быструю логику работы, без лишних запросов; - исключается криворукость контент-менеджеров, которые могут случайно удалить код со страницы. Удалять компоненту со страницы у менеджера рука обычно не поднимается, а если и удалит - легко её вернуть назад; - создание своего шаблона через веб-интерфейс (не нужно лезть по ssh и копировать компонент для кастомизации);
Вобщем, себе я такой компонент создал, вещь удобная и нужная. Особенно для таких ленивых как я.
В шаблоне уже созданы файлы result_modifier.php и файл .paramters.php с пустым массивом настроек, и закоментированным примером. При желании можно в него легко и быстро добавить свои параметры.
Идея хороша. В работе постоянно использую свои базовые компонеты - для вывода списка элементоd, списка секций и детального описания (CIBlockElement::GetList и CIBlockSection::GetList соответственно), но этот компонент мне даже больше нравится, только его надо немного модифицировать добавить условие кеширования, а то убивается постраничная навигация... как-то так
Иван, вы несколько не так поняли идею компонента. Он живет также как и другие компоненты, его шаблоны можно копировать. Просто весь "пафос" убран и в результ_модифире просто "тупо" рабочий код.
Снипет подразумевает размещение исполняемого кода на публичной странице, что не правильно в логике Битрикса.
Да, мне тоже очень понравилась Его можно использовать для абсолютно разных нетипичных задач. За неделю уже раз 5-7 использовал данную компоненту на разных проектах. Например, сегодня добавил форму получения прайс-листа только после введения контактных данных http://toyota-ua.com/service/spares/
Сейчас думаю в сторону создания такого комплексного компонента (например для сложного каталога), пока изучаю возможные подводные камни.
Идея очень хороша, думаю, тоже найду не мало возможностей ей воспользоваться! 8) В такие моменты перед самим собой становится как-то стыдно, что сам не додумался до такой, казалось бы, простой вещи.
Сейчас думаю в сторону создания такого комплексного компонента (например для сложного каталога), пока изучаю возможные подводные камни.
В правильную сторону думаете Могу подкинуть камней, по поводу собственной компоенты под эти нужды сам давно думаю, но тоже дальше мыслей пока не идет. По сути реально "сложный" компонент каталога, как мне кажется, подразумевает возможность отображения ПЕРСОНИФИЦИРОВАННОЙ информации каждому конкретному пользователю. Что-то общее, универсальное выделить можно, но от проекта к проекту эти вещи все-же разнятся. Поэтому сейчас мне ничего не мешает все же просто брать предыдущие API наработки с других сайтов и обстругивать их под новые нужды. А если писать под это дело компонент, то вроде и хорошо - взять хотя бы ваши плюсы, изложенные в начале вашего поста. Но два ключевых для меня момента все же в плюсы такого компонента не попадут, а именно:
- данные в файле result_modifier.php кешируется
информация для каждого пользователя своя, поэтому кеширование отпадает (либо делать для каждого пользователя свой кеш? что мне кажется, накладно).
- мы можем написать абсолютно нужную и быструю логику работы, без лишних запросов
в таком деле опять же каждый запрос на счету, поэтому получается проще использовать аскетичный API, чем какой либо универсальный компонент.
информация для каждого пользователя своя, поэтому кеширование отпадает (либо делать для каждого пользователя свой кеш? что мне кажется, накладно).
Обычно кешируют группу пользователя, так как права в одной группе у всех обычно одинаковые. Для этого надо в массив переменных, от которых зависит кеш, добавить группу пользователя. Точно так же как человек ответом выше советовал добавить в параметры кеша еще и номер страницы при постраничной навигации.
в таком деле опять же каждый запрос на счету, поэтому получается проще использовать аскетичный API, чем какой либо универсальный компонент.
Обычно кешируют группу пользователя, так как права в одной группе у всех обычно одинаковые.
Само-собой, когда есть такая возможность, но бывают слишком сложные варианты, когда для каждого пользователя именно своя цена, пример я приводил на форуме.
да, поэтому я и использую этот компонент
Согласен, в этом случае компонент диво как удобен.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».