abushyk

Судя по моим записям с версии 1.1.4 и было исправление.

если у вас нет локального обработчика, который обабатывает ваш кастомный параметр или нет его обработки в template_search, то не знает. если одним из этих способов вы его учли и обработали, то знает. научить его. например в темплейт_сеарч у вас была обработка одного параметра. в getParams if(''!==$this->getRequestValue('имя_параметра')){ $params['имя_параметра'] = intval($this->getRequestValue('имя_параметра')); } станет if(NULL!==$this->getRequestValue('имя_параметра')){ $v=$this->getRequestValue('имя_параметра'); if(!is_array($v)){ $v=(array)$v; } foreach($v as $k=>$_v){ if(0==intval($_v)){ unset($v[$k]); } } if(!empty($v)){ $params['имя_параметра'] = $v; } } т.е. получаем из запроса, чистим от значений которые не число большее нуля и отдаем далее. А потом в run() обрабатіваем if(isset($params['имя_параметра'])){ $where_array[]=DB_PREFIX.'_data.`имя_параметра` IN ('.implode(',', $params['имя_параметра']).')'; } Эот пример для переменных, передающих целые числа. Для других будет примерно та же логика с некоторыми изменениями при проверке и формировании запроса.

<div class="type control-group"> <label class="control-label">Тип чего-от там</label> <div class="controls"> <select name="tip_stroy"> <option value="0">выбрать</option> <option value="1"{if isset($smarty.get.tip_stroy) && intval($smarty.get.tip_stroy)==1} selected="selected"{/if}>Кирпич</option> <option value="2"{if isset($smarty.get.tip_stroy) && intval($smarty.get.tip_stroy)==2} selected="selected"{/if}>Панель</option> <option value="3"{if isset($smarty.get.tip_stroy) && intval($smarty.get.tip_stroy)==3} selected="selected"{/if}>Дерево</option> ... <option value="100"{if isset($smarty.get.tip_stroy) && intval($smarty.get.tip_stroy)==10} selected="selected"{/if}>Другое</option> </select> </div> </div> и все. есть и минусы - нужно следить за целостностью. т.е. если в аналогичный элемент в модели вы добавите новый тип, то необходимо его же добавить и в шаблоне.

Если у вас только пользовательская форма поиска и она достоверно одна, то стандартній вівод {if isset($local_search_forms) && $local_search_forms|count>0} <ul class="nav nav-tabs" id="search_forms_tabs"> <li><a href="#main_sf" data-toggle="tab">Все</a></li> {foreach from=$local_search_forms key=ftname item=ftdata} <li{if $ftdata.active==1} class="active"{/if}><a href="#{$ftdata.id}" data-toggle="tab">{$ftname}</a></li> {/foreach} </ul> {else} {/if} {if isset($local_search_forms) && $local_search_forms|count>0} <div class="tab-content"> <div class="tab-pane" id="main_sf"> {include file='standart_search_form.tpl'} </div> {foreach from=$local_search_forms key=ftname item=ftdata} <div class="tab-pane{if $ftdata.active==1} active{/if}" id="{$ftdata.id}"> {$ftdata.body} </div> {/foreach} </div> {else} {include file='standart_search_form.tpl'} {/if} превращается в {if isset($local_search_forms) && $local_search_forms|count>0} {foreach from=$local_search_forms key=ftname item=ftdata} <div> {$ftdata.body} </div> {/foreach} {/if} т.е. вікидівается строка с корешками табов. выкидывается вкючение стандартной формы. остальные формы (которых реально одна) выводятся просто в DIV-элемент без примочк и классов от tab-плагина, что бы оно не скрывалось и не пыталось вести себя как набор закладок.

Это плохой способ комментирования. Не стоит оборачивать встраиваемый шаблон хтмл-комментариями, так как в нем могут быть такие же комментарии, а они не могут быть вложенными. <!-- <div class="tab-pane" id="main_sf"> {include file='new_search_form.tpl'} </div> --> вот так лучше. Сначала комментируется включение, а потом оборачивающий его блок. <!-- <div class="tab-pane" id="main_sf"> {*include file='new_search_form.tpl'*} </div> -->

Кавычки, а точнее скобки, следует ставить в тех параметрах, которые передаются не в единственном числе. Если вы передаете параметр a одним значением, то передаете его a=5, а если нужно передать под одним именем набор значений тогда a[]=5&a[]=8&a[]=100. Это теория. Практика же состоит в том, что если обрабюотчик не обрабатывает случай, когда одна переменная передана как ассив значений, то хоть вы с кавычками передавайте, хоть без, он ее не обработает как массив. В лучшем случае как скаляр. Т.е. кавычки это просто запись данных, но они никак не влияют на то, кто примет эти данные и как он их примет и обработает. В системе предусмотрена обработка отдельных параметров как в виде одного значения, так и в виде массива. Это география (города, страны...), ЖК и возможно еще что-то. Если у вас есть рукотворный селектбокс, то 99,9% что обработчик его не обраотает так, как вы ожидаете, так как он про него не знает. при такой записи действует правило "замена последним". так что на входе вы получите topic_id=2 И city_id=2 И remont=2

А настройка "Общие"-"Разрешить поиск по тэгам во фронтенде (allow_tags_search_frontend)" включена или нет?

Да. Это сводится к изменению шаблона realty_grid.tpl и включаемых им. Можете искать по темам с упоминанием его или по словам "изменить сетку, свой вывод в списке, шаблон списка"

Да, ошибка в пейджере была исправлена.

1) создать в редакторе форм свою таблицу-дата-спрачоник-нотариусов например - Да (это в какой-то мере обязательное действие)2) потомвзять за аналог вывод новостей - Да\Нет (только если нужен "вычурный" функционал)3) в main.tpl написать код выборки по справочнику нотариусов присвоив ей например переменную $notarius - Как вариант. Только не в main.tpl а в main.php4) создать пустой tpl и вставить в него $notaruis в любом css исполнении используя цикл вывода? - В общем да. В предыдущем шаге вы получили данные и отправили их в шаблон. А дальше уже включаете шаблон, или файл шаблона, или прямо в main.tpl где нужно и в нем циклом или иным способом выводите выбранное

не нужно, а можно. есть случаи, когда системного функционала достаточно, есть - когда нет и все-равно нужно будет писать свой код. она будет доступна под определенным системой именем (я пару сообщений выше описал все доступные имена). Это если использовать системные возможности. если же вы делаете выборку данных сами, то, естественно, имя переменной с данными будет таким, как вы его назначите. "Справочники" (так обычно называют любую таблицу с данными), если они пользовательские, доступны после создания для них в редакторе форм обработчика в верхней панели, возле кнопки Приложения. Т.е. процесс таков - а) создается в Редакторе форм таблица-модель б) на нее навешивается дефолтный обработчик (что бы в админке можно было получить к ней доступ в привычном виде список-форма). Только после этого она появится под кнопкой Пользовательские в верхней панели админки. Справочники в колонке слева админки - это просто сборник условно-системных справочников (нечто вроде часто используемых). Но там далеко не все "справочники", а только география.

я про настройки пользовательских справочников говорю, которые стали доступны после обновки. если вы пытаетесь решить это иным путем, то это будет делаться не в шаблоне, а именно в коде. т.е. запошеный вами кусочек копипасты не изменится, а изменится код, который поставляет данные для этого кусочка.

добавить в справочник поле sort_order под числа, указывающие приоритетность, а для фронта справочника указать сортировку по этому полю. опять же там же параметр "на страницу".

принцип вывода пользовательского справочника не претендует ни на универсальность, ни на суперфункциональность. он предназначен для быстрого и тривиального вывода некоторых данных с информационной целью. все остальные плюшки, как то фильтрация по параметра, изменяемая сортировка, вывод в карточке объекта дополнительных однотипных объектов а-ля "похожие" или связка этого объекта с другими объектами сайта уже выходят за рамки тривиального и при попытке сделай какой-то абстрактный модуль, который будет одинаково успешно управлять разнородными сущностями - маловероятно. это не админка, где базовые операции сводятся к определенному кругу действий (CRUD - создать-изменить-удалить-показать). на фронте всегда будет куча всякой логики, связей и прочего. и попытка все это абстрагировать и универсализировать, как показывает опыт, к хорошему не приведет. ПС. Это не вторая ветка развития - это просто сравнительно удобный и быстрый способ сверстать и наладить вывод инфы не прибегая к услугам разработчика по разработке целого приложения. не более.

Убираем накладку учета прав доступа для админки: Файл /apps/customentity/site/site.php строку 15 $query='SELECT `entity_name` FROM '.DB_PREFIX.'_customentity WHERE `alias`=? AND `is_public`=?'; меняем на $query='SELECT `entity_name` FROM '.DB_PREFIX.'_customentity WHERE `alias`=? AND `is_public`=?'; строки 18-20 $ar=$DBC->fetch($stmt); $ent=self::getEntityList(); $cent=$ent[$ar['entity_name']]; меняем на $cent=$DBC->fetch($stmt); строку 47 $query='SELECT `entity_name` FROM '.DB_PREFIX.'_customentity WHERE `alias`=? AND `is_public`=?'; меняем на $query='SELECT * FROM '.DB_PREFIX.'_customentity WHERE `alias`=? AND `is_public`=? LIMIT 1'; строки 50-52 $ar=$DBC->fetch($stmt); $ent=self::getEntityList(); $cent=$ent[$ar['entity_name']]; меняем на $cent=$DBC->fetch($stmt); Эти же изменения будут проведены в новой версии приложения, так что ни что не затрется.

Это приложение именно это и делает. Только избавляет вас от того, что бы своими руками "взять переменную и отдать", так как за этим не длинным выражением все-таки скрывается некоторый специфичный набор вспомогательной работы)))

100% там внутри таки есть проверка прав доступа. завтра я посмотрю, как ее ласково обойти.

для uploads фотки лежат в .value поле. Внутри него лежат элементы фоток. У єтого єлемента есть поля .preview, .normal - для превьюшки и большой фотки. Если на примере, то допустим что в модели сущности фото-поле имеет имя my_uploads_field_name {if is_array($entity_item.my_uploads_field_name.value) && !empty($entity_item.my_uploads_field_name.value)} {foreach from=$entity_item.my_uploads_field_name.value item=photo} Это маленькая картинка - <img src="{$estate_folder}/img/data/{$photo.preview}" /> <br /> Это большая картинка - <img src="{$estate_folder}/img/data/{$photo.normal}" /> {/foreach} {/if} Что для списка, что для карточки будет одинаково.

В редакторе форм откройте на редактирование элемент модели который у вас с автокомплитом. Там есть секция Параметры и уже есть параметр autocomplete со значением 1. Добавьте ниже параметр autocomplete_notappend и тоже единичку как значение.

совершенно верно. это о том, как показать на люди свой внутренний справочник с минимальным телодвижениями и простейшим функционалом. Доступно с последнего обновления customentity-приложения. Не уверен на 100%, но кажется там не было зависимости от других приложений (но могу ошибаться), так что в теории можно попробовать стянуть только его и добавить нужные поля в модель customentity под новые параметры.

Тогда будет логичнее не подгружать алиасы "на всякий случай" и использовать в шаблоне, а вынести его выборку в модуль карточки, где он будет выбираться и передаваться только тогда, когда запрошена карточка, и тогда передавать его в шаблон вместе с данными о объекте. Это так же будет более рациональным, если ссылки используются только в карточках, но не используются в тех же списках объектов. Плюс можно оптимизировать будет выборку алиасов. Не брать их сразу все и хранить какое-то время, а брать только запрощенные и сохранять, а новые добавлять в эту сохраняемую коллекцию, которую очищать в случае а) истечения времени хранения, б) при достижении нею некоторого пограничного значения (например на сохранении уже стоит 1000 ссылок, значит можно сбросить все и начать собирать наново). Но это в теории. Такую оптимизацию нужно делать по результатам хотя бы метрики, что бы понимать насколько разные ЖК смотрят люди и насколько часто вообще открываются карточки, где используются эти алиасы.

Используем свежие возможности приложения Редактор форм. 1. Настройка модели. В Редакторе форм находим необходимую нам таблицу-источник данных. В данном примере это будет eventm_event - таблица, содержащая какие-то объекты типа "событие". Используя кнопку 1 на скрине, создаем обработчик для этой таблицы (как это и делалось ранее). Название - указываем название для обработчика под которым оно будт показываться в списке пользовательский приложений в админке Публичный - признак, который разрешает приложению показывать себя наружу. Если вы помните, то ранее все пользовательские приложения были доступны только в админке. Установив эту галочку вы можете расшарить его и наружу, в фронт сайта. Алиас - это урл, по которому будет доступно ваше приложение на фронте сайта, если вы отметите галочку Публичное. В данном случае наше приложение будет видимо по адресу мой_сайт/events Шаблон списка - имя файла-шаблона, который будет формировать список выводимых сущностей на фронте Шаблон объекта - имя файла-шаблона, который будет формировать детальный просмотр конкретной сущности на фронте NB. Если не указать имена шаблонов, то на каждой из этих страниц вы получите вместо списка и детального просмотра предупреждение вида Здесь должен быть шаблон для списка объектов модели Разместите шаблон для этого вывода в папке /template/frontend/ВАША_ТЕМА/apps/customentiry/site/template/ИМЯ_ШАБЛОНА.tpl и укажите имя шаблона (ИМЯ_ШАБЛОНА.tpl) в настройках обработчика. Доступные в этом шаблоне переменные: {$entity_list} - массив объектов {$entity_pager} - постраничная навигация {$entity_info} - информация о текущей модели и Здесь должен быть шаблон для объекта модели eventm_event Разместите шаблон для этого вывода в папке /template/frontend/ВАША_ТЕМА/apps/customentiry/site/template/ИМЯ_ШАБЛОНА.tpl и укажите имя шаблона (ИМЯ_ШАБЛОНА.tpl) в настройках обработчика. Доступные в этом шаблоне переменные: {$entity_item} - просматриваемый объект {$entity_info} - информация о текущей модели которые будут подсказывать, что именно не так и почему. Дефолтных и заглушечных шаблонов для этого приложения не существует. Поле сортировки - тут необходимо указать системное имя одного из полей модели сущности, по которому будет проводиться сортировка перед выводом. По умолчанию это поле-первичный ключ. Направление сортировки - одно из значений asc (по возрастанию) или desc (по спаданию). Если не указано явно или указано любое другое значение, кроме этих двух, то сортируется по спаданию значения. Количество на страницу - число объектов на странице списка (по умолчанию - 10). Заполняем поля и сохраняем обработчик. 2. Шаблонизация Указанные файлы шаблонов необходимо разместить в папке /template/frontend/ВАШ_ШАБЛОН/apps/customentity/site/template/ Найдя их там, обработчик подключит их, передаст в них данные и выдаст в сайт результат. 2.1 Список Минимальный шаблон для вывода списка событий <ul> {foreach from=$entity_list item=entity_item} <li><a href="{$entity_item._href}">{$entity_item.name.value}</a></li> {/foreach} </ul> {$entity_pager} В шаблоне списка присуствуют следующий переменные: $entity_list - массив моделей текущей страницы списка. Перебирая в цикле эту переменную вы получаете элемент массива, который имеет такую же структуру как и объект, который вы выводите в карточке объекта. Т.е. если у вас есть в модели поле owner_name типа safe_string, то вы можете вывести его как {$entity_item.owner_name.value}. А если есть поле gorod вида списка-выпадашки с вариантами из таблицы городов, то {$entity_item.owner_name.value_string} - получаем текстовое значение и {$entity_item.owner_name.value} - получаем числовой индекс (где $entity_item - это каждый элемент массива $entity_list). Модель объекта, передаваемая в шаблон, что в списке, что в детальном просмотре, не учитывает права видимости по группам смотрящего. Иными словами в шаблон приходит полная модель, а логику скрытия чего-то вы можете реализовать внутри шаблона. Вместе с данными модели, каждый элемент массива в списке содержит служебное поле _href в котором записана ссылка на детальный просмотр данного объекта списка (в терминах рассматриваемого примера - на карточку конкретного события). {$entity_item._href} - это ссылка на "страничку" данного объекта, которую можно просто вписывать в аттрибут href тега ссылки. Все ссылки формируются по принципу алиас_сущности/ID_объекта. Так что для нашего примера все ссылки на конкретные события будут иметь вид сайт/events/N , где N = 1,2,3,..... В итоге по приведенному шаблону мы получим вывод вида (для примера я изменил количество объектов на странице на 2 вместо 10): 1 - это наш список. Тут я просто вывел заголовки событий. 2 - пейджер, доступный в переменной $entity_pager. Если все объекты влезли на первую страницу, то пейджер будет содержать пустую строку. 2.2 Карточка Принцип абсолютно тот же, что и для списка, только в этом случае в шаблон приходят две переменные: {$entity_item} - полная модель просматриваемого объекта {$entity_info} - информация о текущей модели Т.е. если у вас есть в модели поле owner_name типа safe_string, то вы можете вывести его как {$entity_item.owner_name.value}. А если есть поле gorod вида списка-выпадашки с вариантами из таблицы городов, то {$entity_item.owner_name.value_string} - получаем текстовое значение и {$entity_item.owner_name.value} - получаем числовой индекс.

Пока забываем все, что я написал ранее. Я не вникал детально в работу этого модуля, но сейчас, пройдясь по коду, понял, что все немного не так. Он весь работает по первому методу - опираясь на поля, определенные пользователем. Т.е. варьирования вывода через шаблон тут нет и надобности копировать-наследовать файлы в данный момент нет никакой. Т.е. сам алерт с вопросом как выгружать, с расширенным или без, в данном случае не нужен совсем.

пока не знаю. эти два варианта могут просто быть не совместимы одновременно.

он идет частично с приложением memorylist. Дима потом посмотрит включил ли он его в обновки. Файлы сами по себе не появятся в вашем template/frontend/шаблон/apps/pdfreport/ в том то и фишка, что их нужно создавать самому, беря за основу файл /apps/pdfreport/admin/template/data_grid.tpl (т.е., копируем, переименовываем в нужное имя и дальше меняем логику вывода)