abushyk

Не, последний вариант вообще для стандартного селектбокса без автокомплита и тлокейшн.

denkurgan, для вашего случае есть еще вариант. Если вы реализуете инициализацию города по умолчанию как я написал выше, то город то выставится, но вот улицы для него не подгрузятся, так как они подгружаются по событию изменения состояния селектбокса. Можно сделать иначе. Создать файл init.js в папке со скриптами шаблона. В нем сделать запись $(document).ready(function(){ if($('div#simple_search [name=city_id]').val()==0){ $('div#simple_search [name=city_id]').val(3); $('div#simple_search [name=city_id]').trigger('change'); }});и подключить этот файл в форму поиска. Тогда, если ваш селект пришел с "пустым " значением, скрипт выставит нужный город и дернет событие изменения селекта, по которому стартует подгрузка улиц.

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

стоп. так дело не пойдет. в $city_list у вас кусок хтмл-разметки, поэтому сравнивать его с нулем бессмысленно. если хотите выставить город в форме, тогда надо в kvartira_search или его локальном заменителе, там где строки if ( $this->getConfigValue('city_in_form') ) { $this->template->assert('city_list', $form_generator->get_single_select_box_by_query($kvartira_model['data']['city_id']));}изменить так if ( $this->getConfigValue('city_in_form') ) { if((int)$kvartira_model['data']['city_id']['value']==0){ $kvartira_model['data']['city_id']['value']=3; } $this->template->assert('city_list', $form_generator->get_single_select_box_by_query($kvartira_model['data']['city_id']));}Но в самом шаблоне вы уже не имеете возможности влиять на селектбокс. Только яваскриптом.

а мы о чем говорим? а, понял, вы все еще автокомплит насилуете.

Не понял. Вы же там выше скриншот с параметрами давали.

имеете в виду, что default_city_id = 3 не срабатывает?

Я, когда описывал отличия между автокомплитом и тлокейшн, указывал, что первый предназначен для работы с хешами, а не стрктурами. Т.е. автокомплит облегчает работу с "грязными" базами в которых было, сознательно или нет, опущено установление связей между адресными элементами. Верно подмечено. Зато в базе нет избыточности - пятидесяти улиц Ленина из 50-ти разных городов)

Это некая вариация в стиле живого поиска получается. Как вот здесь в поиске http://www.booking.com

Ну, дефолтная не значит лучшая) Просто никто особо не протестует. Я вот только не уверен, что стоит выделять в отдельную таблицу подтип. Ведь если у подтипа появится тоже подтип, то по логике нужны будет четвертая таблица - а так можно ой как обрасти.

Как вариант. В файле main.php шаблона if($_SERVER['REQUEST_URI']=='/'){ $this->template->assert('we_are_on_main', 1);}и уже внутри шаблона, проверяете это условие {if $we_are_on_main==1} тут выключаем или включаем то, что не должно или должно быть на главной{/if}Только тут надо выяснить, что считать главной страницей. Ту, адрес которой в строке браузера выглядит как имя домена без параметров? Форма поиска подключается в /template/frontend/realty/big_tabs.tpl.html где-то в 46- строке конструкцией вида {include file="search_form.tpl"}

Небольшой оффтоп. Уже сложилась практика создания структуры категорий в виде Продажа-Квартиры, Продажа-Комнаты, Аренда-Квартиры, ... Т.е объединения в одно целое различных понятий - типа недвижимости и вида операции с ней. имхо - это плохая практика. Ведь недаром стараются вести отдельно параметры жилой и общей площади. С ними тогда значительно удобнее работать, сравнивать, фильтровать, чем со значениями вада ааа/ббб. Если все упирается в создание меню навигации в виде выпадающих списков, то затраты от разработки такого меню не есть больше минусов от содержаний структуры в виде смешанных понятий. Теперь чисто теоретически. Имеем таблицу re_data, re_topic, re_rubrika (объявления, типы недвижимости, рубкрики (как-то Продам, Сдам, Сниму)). Как получить сводную матрицу количеств обїявлений: $ads_count_matrix=array();$DBC=DBC::getInstance();$query='SELECT COUNT( d.id ) AS dcount , t.name AS tname, r.name AS rnameFROM re_data dLEFT JOIN re_topic t ON d.topic_id = t.idLEFT JOIN re_rubrika r ON d.rubrika_id = r.rubrika_id WHERE d.active=1GROUP BY d.topic_id, d.rubrika_id';$stmt=$DBC->query($query);if($stmt){ while($ar=$DBC->fetch($stmt)){ $ads_count_matrix[]=$ar; }}В результате мы получаем массив вида: [0][dcount]='10'[0][tname]='Квартиры'[0][rname]='Продам'[1][dcount]='2'[1][tname]='Комнаты'[1][rname]='Продам'[2][dcount]='1'[2][tname]='Квартиры'[2][rname]='Сдам'[3][dcount]='0'[3][tname]='Комнаты'[3][rname]='Сдам'...Дальше уже дело техники. Либо скинуть этот массив в шаблон и там его просто вывести, либо в контроллере обработать его дополнительно - упорядочить по рубрикам, типам и тогда уже скинуть в шаблон для вывода. Если рубрики\категории слиты в единую структуру, то принципиально решение будет похожим, но будет больше мороки с упорядочиванием, так как надо будет вычислить какие типы в какие рубрики входят и свести их.

О каком шаблоне идет речь?

В общих чертах так: 1. создается локальный grid_manager в котором, кроме формирования списка объявлений по заданным фильтрам, собирается еще и более полная информация по каждому объявлению. 2. в шаблоне вывода сетки предусматривается формирование разметки, для вывода этих данных. 3. с помощью скрипта создается прятанье\показывание этой информации. one-click решения не существует.

Теперь по матричному выводу продам\куплю - жилая\нежилая. Эти рубрики являются одним параметром. т.е. все это структура типа Продам Жилая недвижимость Новостройки Вторичное жильеКуплю Жилая недвижимость Новостройки Вторичное жилье?

Общее количество объявлений. Блиц-решение. Это вставляем в файл main.php шаблона. Можно в самом начале $total_ads_on_site='';$DBC=DBC::getInstance();$query='SELECT COUNT(id) AS total_ads_on_site FROM '.DB_PREFIX.'_data WHERE active=1';$stmt=$DBC->query($query);if($stmt){ $ar=$DBC->fetch($stmt); $total_ads_on_site=$ar['total_ads_on_site'];}$template->assert('total_ads_on_site', $total_ads_on_site);В шаблонах теперь доступна переменная {$total_ads_on_site} с числом объявлений. Прям ее можно вставлять там, где необходимо.

Конфигпараметр link_street_to_city установить в выбранное состояние. Это не то? Хотя в этом случае надо будет вручную привязать улицы к городу.

А районы привязаны к городу?

Нет. Но можете применить стили косвенно, через указание привязки к родительскому элементу. Например, если у вас {$country_list} в форму выводится как <div class="someclass_for_countrylist">{$country_list}</div>то можно обцеэсэсить его следующим образом .someclass_for_countrylist select { /*тут стили*/}Но не забывайте, что не все элементы столь прямолинейны. Для вывода автокомплит-элементов используются возможности jqueryUI, поэтому стили надо применять к конечному элементу, который создает жиквери.

Вы оказались правы. Я внес правку в системный data_form_front.tpl. Думаю завтра Дмитрий выпустит обновление system.

Это вам может ответить Дмитрий. Я про такие индексы слышу впервые.

Никак. При обработке данных от пользователя из ЛК 1. Поле user_id средствами цмс инициируется значением ид текущего пользователя. Т.е., что бы вы не передали с сайта, в поле юзера всегда будет указан текущий пользователь. 2. Поле user_id средствами цмс ставится в скрытое состояние. Т.е. его не видно в форме так как оно проходит hidden элементом формы. Но даже если вы его поинициируете, например, скриптом, все равно сработает пункт 1. В данный момент все попытки реализовать вашу схему - бессмысленны. Так как, что бы пользователь С мог сменить владельца объявления с А на Б,ему надо получить это объявление на редактирование. Но получить объявление в ЛК, владельцем которого есть А, на редактирование можно только под логином А. Логика понятна? Выставление видимости поля юзер_ид в модели для групп тоже ничего не даст, так как опять сработает пункт 1. Это ЛК, а не админка, доступная с фронта. Поэтому и такая своя логика. Тут выходом может быть адаптация ЛК под вашу систему ролей.

Значит урлы для категорий у вас уже прописаны. Эта опреация затрагивает только урлы категорий. Но не урлы для объявлений. Прописать валидные урлы для объявлений можно будет при пересохранении объявления, либо дождавшись версии 1.1.1 приложения СЕО-Оптимизация. Там будет кнопка для автоматизации этого процесса.

Есть маленький баг\фича - в силу структуры запроса к БД, в вывод не попадают объявления, для которых не указан раздел из таблицы re_topic (topic_id)

У вас нет в форме поля Категория\Тип?