abushyk

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

Смотрите. Есть два типа урлов для объявлений. 1. ЧПУ или SEO - это тот, который вы привели в примере 2. Базовый (когда ЧПУ урлы не включены) в виде /realty1235 либо /realty1235.html Вот эта опция про .html включает постфикс только для второго типа урлов.

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

Итак, мы имеем набор полей: is_wifi Наличие интернета - поле типа checkbox. На форме присутствует в сиде чекбокса. floor_type Тип покрытия пола - select_box с вариантами {0~~не указано}{1~~плитка}{2~~дерево}{3~~ламинат} - отображается в виде выпадающего списка sea_distance Расстояние до моря. Тип safe_string, но отмеченный как is_ranged=1, что бы в форме поиска выводилось в виде двух полей - макс. и мин. значения. Мы добавили эти поля в модель, каким-то образом разместили их на формах поиска. Теперь главная задача - заставить движек обработать их. Для этого существует файл шаблонного поиска, который размещается в /template/frontend/имя_шаблона/main/ и носит имя template_search.php и не иначе. При наличии этого файла движек автоматически обратится к нему и запросит данные для осуществления выборки. В минимальной комплектации этот файл состоит из класса и двух функций: http://pastebin.com/TmBSS9q8 Задача функции getParams забрать данные из запроса и подумать, стоит ли их передавать дальше. А функции run, к которой обращается движек за данными, решить каким образом следует сравнить\обработать полученные параметры для формирования нужной выборки данных. Итак, поехали. 1 Начнем с самого простого - чекбокса is_wifi. Чекбоксы отличаются тем, что в запросе они либо приходят, либо нет. Из запроса берем его функцией $this->getRequestValue('is_wifi'), которая возвращает значение NULL, если такого параметра не существует. if(NULL!==$this->getRequestValue('is_wifi')){ $params['is_wifi'] = 1; } Проверили, не пусто ли, если нет, значит чекбокс отметили и мы записываем его в $params в виде утвердительной единицы. Единицы потому, что в принципе больше нам инфы не нужно, достаточно знать, что параметр запрошен. Дальше floor_type. Этот тип передается в запрос в виде ключа своих значений. Т.е. выбрав "дерево" в запрос у нас приедет "2". Значит мы знаем, что будет целая цифра. if(0!==(int)$this->getRequestValue('floor_type')){ $params['floor_type'] = (int)$this->getRequestValue('floor_type'); } Мы гарантированно делаем из значения параметра целое число с помощью (int) и сравниваем его с 0 - нашим значением никакого значения. Если оно не равно нулю, значит пользователь запросил конкретный тип покрытия и мы сохраняем его значение в $params['floor_type']. Но сохраняем уже конкретным начением, таккак, в отличии от чекбокса, тут нам важно само значение, а не его наличие. sea_distance. При использовании пользовательских форм, которые енерирует движек на основе ваших выборок это поле представится в виде двух полей с именами созданными по принципу sea_distance_min и sea_distance_max. Соотв. и дву переменные прийдут в запросе. Каждую ловим отдельно. Для простоты допустим, что мы готовы обработать целые расстояния до моря: 1, 5, 100. if(0!==(int)$this->getRequestValue('sea_distance_min')){ $params['sea_distance_min'] = (int)$this->getRequestValue('sea_distance_min'); } if(0!==(int)$this->getRequestValue('sea_distance_max')){ $params['sea_distance_max'] = (int)$this->getRequestValue('sea_distance_max'); } Принцип прост. Мы приводим значение к целому. Если пользователь вписал в поле не число, а "аврцуоац" строку, она приведется к нулю. И сравниваем все это с нулем. Искать по нулевому значению смысла нет, поэтому мы сохраняем только те значения, которые от него отличны. Разницы между мин и макс значением в момент их забора из запроса мы не делаем. Она не важна сейчас, но будет важна в следующей функции. 2 Переходим к функции run() Методика ее работы такая 1. взять параметр 2. создать кусочек запроса. Для чекбокса if(isset($params['is_wifi']) && isset($data_model_array['is_wifi'])){$where_array[]=DB_PREFIX.'_data.is_wifi=1';}Расшифровка. Проверяем, есть ли в параметрах запроса переменная is_wifi и есть ли в нашей модели поле с таким именем (так как условие может быть, а поле мы давно погасили за ненадобностью). Если все эти условия выполнены, мы указываем, что хотим дополнить условия нашего запроса сравнением, которое выберет записи, где is_wifi равно1, т.е. при сохранении записи был отмечен чекбокс. Для floor_typeif(isset($params['floor_type']) && isset($data_model_array['floor_type'])){$where_array[]=DB_PREFIX.'_data.floor_type='.$params['floor_type'];}Все аналогично предыдущему за исключением того, что тут мы просим сравнить поле floor_type записи, которое хранит ключ указанного типа покрытия, с переданным в запросе. Для ранжированного sea_distance if(isset($params['sea_distance_min']) && isset($data_model_array['sea_distance'])){$where_array[]=DB_PREFIX.'_data.sea_distance*1>='.$params['sea_distance_min'];}if(isset($params['sea_distance_max']) && isset($data_model_array['sea_distance'])){$where_array[]=DB_PREFIX.'_data.sea_distance*1<='.$params['sea_distance_max'];}И тут почти без изменений. Главное отличие - мы устанавливаем условия в зависимости от того _max или _min параметр мы хотим сравнить. Обратите внимание на DB_PREFIX.'_data.sea_distance*1. В неоптимизированных БД сайтбилля поля под safe_string имеют строковой тип. Поэтому, что бы не было строкового сравнения, где строковое "2" больше строкового "100", мы принудительно делаем значение поля числом перед сравнением. И тогда уже будет натуральное сравнение, где 2<100. и вот примерно вот так http://pastebin.com/8jX7WEEH все єто будет выглядеть в конце.

В данный момент адреса такие appalias/ безразборный список новостей appalias/categoryalias/ список новостей в категории appalias/newsalias/ новость де appalias - настраиваемый алиас приложения, по дефолту news варианта appalias/categoryalias/newsalias/ пока нет, но хочется.

Какая кнопка съехала, что скролл появился? Я вроде нигде прокрутки не наблюдаю.

Не верно написано название файла библиотеки. Не jquery.jcarousellight.js а jquery.jcarousellite.js Она как-раз идет в стандартном комплекте этого шаблона.

Что не ясно с категориями?

1. Качаем отсюда http://my.digitalwerkstatt.ru/files/news.zip "ночной" релиз приложения. 2. Свое приложение копируем в сторону. На его место распаковываем скачанное. 3. Если таблицы уже созданы и наполнены, проверяем наличие полей в re_news meta_title varchar(255) meta_keywords textmeta_description textnewsalias varchar(255) в re_news_topic url varchar(255) 4. Если не созданы или пусты, тогда сносим старые таблицы re_news_... и в админке делаем /admin/index.php?action=news&do=install 5. Алиас новости формируется из заголовка новости. Но только тогда, когда вы не заполните поле алиаса в форме. Т.е. если вы хотите свой алиас, не похожий на заголовок, просто вбейте его в соотв. поле. Для категорий поле url аналогично. Алиас, рукотворный, ввоодится латинницей и состоит из допустимых символов - буквы, цифры, подчеркивание и тире. 6. Адреса ссылок в списке новостей будут строится с учетом этого алиаса.

Звездочка в иконках под фоткой.

/template/frontend/estetico/realty_grid.tpl Этот файл является оболочкой для вывода сетки (читай категории). Дополните его {if $smarty.request.page == 1 or $smarty.request.page == '' }<span itemprop="description">{$description}</span>{/if}для вывода описания категории.

Разница в пункте назначения. Один формирует выгрузку для AFY.ru другой для cian.ru. Выгрузка осуществляется по требованию, сайт-заборщик обращается на спецадрес, где и получает выгрузку. По умолчанию в выгрузке учавствуют все активные объявления и отмеченные как подходящие для выгрузки. В принципе круг выгружаемых может быть скорректирован.

Зависит от задач, которые будет выполнять контроллер. Если они тривиальные - то обчно в рамках шаблона делается файл-класс с необходимым функционалом и вызывается в main.php шаблона. Если задачи обширно-глобальные, то можно пробовать реализовать через приложение в папке /apps/

Неудачный пример. Изначально колонка новостей вообще не поддерживала шаблона, а вместе с разметкой создавалась внутри модуля новостей. Постепенно, образовалось приложение новостей, но вот способ включения этой колонки в шаблонах, к тому времени, пророс корнями. И именно это "недошаблон" пришлось подтягивать под наследие. Именно с этим связанно то, что вывод в шаблон {$news_list_column_html} и {include file="news_list_column.tpl"} являются идентичными. А сам шаблон колонки по инерции лежит в папке шаблона, а не, как полагается, в системе подпапок в /apps/. Мы стараемся максимально унифицировать работу с шаблонами приложение, но еще остаются места, которые выбиваются из этой системы "традиционно".

Я может под вечер уже не особо соображаю - можно, так сказать, "в картинках"? Более популярно описать, где чего нет и что не отрабатывает.

Блочек Статьи стоит там как плейсхолдер. В Сайтбилле нет и не было аналогичной сущности, поэтому это место пока пустует.

Это не наше родное. Могу только подозревать, что "r" может означать "reserved" (какой-нибудь бекап). В любом случае из этой папки сайтбилль точно ничего не берет. Хотя стоит учтонить у Дмитрия. Насчет лишнего - согласен, но так сложно удалить то, что когда-то написал, пусть даже сейчас оно и не нужно)

/template/frontend/realty/realty_view_more.tpl Это шаблон подробностей <ul class="realty-options">{foreach from=$hvd_tabbed item=tab key=tabname}...{/foreach}</ul>эти строки знаменуют вывод данных. Перед закрівающим </ul> добавьте<li><label>Количество просмотров</label>{$grid_items[i].view_count}</li>

Тот, что без статика, остался как напоминание, кажется. От старого варианта. Он не столько дублирует, сколько просто присутствует.

Мысль конечно хороша)

setOpt чуть ниже setOptions . Хотя, если честно, я не уловил о чем собственно речь.

Это наверняка показывает, что используется старая версия файлов, когда в администрировании объявления поддерживался только гугль Можно. Из Обновлений приложение должно быть доступно. НО не имеет смысла а) есть некоторые общие полезности в system без которых геодата не сможет нормально работать и б) другие приложения, до обновления, могли использовать некоторые возможности геодаты иначе, чем после.

Тут сложно ответить))) Надо знать куда именно на странице вы хотите вывести эти данные.

Как раз наоборот. На дефолтной форме вас практически ничто не лимитирует ни в плане расположения элементов, ни в плане их количества.

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