Leaderboard

Добрый день всем. Здесь очень часто упоминают тему по рассылке объявлений на доски. Наши модераторы делают всё возможное для улучшения сервиса. Создали преложения например на афи или циан..., портал: http://www.etown.ru/ И всё равно тема по рассылке объявлений не утихает. Многие пишут про авито или яндекс, там хотят закрепится. Для того чтобы туда что-то сливать, нужны большие вложения.... Маленькие компании не могут себе это позволить. Афи вариант хороший, стоит 2000 руб раз и Про-аккаунт в нашем регионе на афи 250 руб в месяц. Афи рассылает на пару досок дальше бесплатно. У меня есть предложение для всего нашего сообщества/пользователей. А что если нам создать совместный портал на подобие http://www.etown.ru/ для рекламных целей? Портал назвать каким либо сообществом риелторов России. Со всех наших сайтов будет уходить на этот проталь объекты недвижимость (как на http://www.etown.ru/). Портал зарегистрировать на всех бесплатных досках и на Афи в том числе (задача модераторов) Пример Афи: в данный момент только для меня одного стоит 250 руб. в месяц. Готов платить эти деньги и даже больше нашим модераторам (всё равно надо платить, так лучше своим, чем чужим). То есть набрали например 10 фирм в сообщество, заплатили абонентскую плату =(10*250 руб) 2500 в месяц нашим модераторам. Они же регистрируют наше сообщество на Афи за 250 руб. как одно целое и размещают все наши объекты с созданного для этих целей портала на афи. Потенциальные клиенты видят наше объявление на афи (контактные данные), читают, имеют возможность перейти на общий портал, а от туда уже на сайты недвижимости (кнопка- посмотреть все объекты специалиста). Для нас как недвижимость удобно: с собственного сайта проходит автоматическая выгрузка на портал, а дальше уже на другие доски. И модераторы не в обиде, делают денежную ставку и модерируют/проверяют занимаются распространением на доски. Смысл заключается в том что, этот портал можно гораздо легче продвинуть на Яндексе и на других досках как авито, где требования и цены для мелких компаний не под силу. Сначала подключить к порталу все бесплатные доски, затем уже всем сообществом думать о платных платформах: авито, из рук в руки.... Толи я один покупаю авито магазин, толи один магазин на всех. Польза видна не вооружённым глазом: 1. цена на платные доски делится на всех (+модераторам за работу) 2. время экономится (с моего сайта уходит дальше и мне больше не надо самому бегать по рекламным доскам, даже афи отпадает) 3. Разработчики получают с абонентской платы 4. ... жду комментарий

Итак, мы имеем набор полей: 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 все єто будет выглядеть в конце.