Leaderboard

1. Предистория Допустим мы имеем базовый сайт на сайтбилле. У нас есть стандартная модель квартиры-недвижимости со всякими Цена, Площадь и прочими свойствами по вкусу. И вот, в один прекрасный момент, мы решили заняться торговлей квартирами в новостройках. А новостройки эти у нас зачастую представлены не отдельными зданиями, а целыми комплексами зданий, которые в свою очередь разбиты на секции. 2. Анализ. Сначала разберемся со структурой. Самый простой вариант - мы решили еализовывать каждую квартиру в виде отдельного объекта. Например, если в ЖК "Элитный" у нас есть корпус А, а в нем секция I и в этой секции, грубо говоря, 15 квартир одной планировки, но некоторые на разных этажах, мы будем считать, что каждая квартира, даже одинаковой планировки - является одним объектом. Иными словами, мы не делаем группировок по типам, а ведем каждую квартиру отдельно. Это дает нам некоторую гибкость, так как квартиры на крайних этажах могут иметь меньшую цену в отличии от одноплановых с ними, на остальных этажах. Так же, из плюсов то, что мы можем задать какие-то особенности поквартирно, даже не смотря на то, что они одноплановые. Особенно это касается, когда квартиры продаются не в сыром виде, а меблированные или с финишной отделкой. Либо учесть иные особенности каждой квартиры. Из минусов такого подхода то, что если секция у нас 9-ти этажная с 4 квартирами на этаж, то на секцию получается 36 объектов. И дальше в геометрической прогрессии в зависимости от количества секций в корпусе и корпусов в ЖК. Соответственно, логично предположить, что кроме обычных для недвижимости параметров (цена, площадь, этаж,и т.д.) нам придется снабдить модель недвижимости дополнительными параметрами, устанавливающими ее привязку к конкретному положению в разрезе ЖК - конкретный ЖК, корпус ЖК, секция корпуса ЖК. И так же очевидно, что при заполнении формы эти параметры должны бы быть связаны цепочкой, как то при выборе отдельного ЖК, мы должны получить под выбор список корпусов только этого ЖК, что бы не рыскать в длиннющем списке всех корпусов. Аналогино и с секциями. 3. Инструментарий. Для реализации нам понадобятся свежие приложения system, admin, table, customentity. Привлекать готовые приложения типа "Жилые комплексы" мы не будем. Из настроек нам будет необходимо включить параметр Настройки - Дополнительно - Off system Ajax. Данная опция выключает автоматические связки между зависимыми элементами и предоставляет нам полный контроль над определением своих зависимостей. Из почитать - http://wiki.sitebill.ru/index.php?title=%D0%A1%D0%B2%D1%8F%D0%B7%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5_%D1%8D%D0%BB%D0%B5%D0%BC%D0%B5%D0%BD%D1%82%D1%8B 4. Подготовка дополнительных сущностей. Если мы должны иметь возможность выбрать корпус, ЖК и секцию, значит у нас где-то должны быть списки этих значений. В Сайтбилле, для организации списков значений существует два типа полей - select_box и selectbox_by_query. Первый нам не подходит, так как не поддерживает организацию наследия. Т.е. штатными средствами этого элемента мы можем задать набор его вариантов значений, но не можем указать какие-то связующие ключи с другим элементом. Второй, поскольку хранится в БД в виде отдельной таблицы, вполне на это способен. Но для его использования необходима соответствующая таблица в БД. В нашем случае таблиц будет три - таблица ЖК, таблица корпусов и секций корпусов. Что бы избавить себя от рутинной работы по наполнению этих данных через phpMyAdmin создадим соответствующие таблицы в Редакторе форм. 4.1. Жилые комплексы. Для ЖК - это таблица czhilkom с полями czhilcom_id (primary_key) и name (safe_string). Создав таблицу и наполнив ее элементами, нажимаем кнопку Создать таблицу. Теперь таблица ЖК существует физически в БД. Надо наполнить ее какими-то жилыми комплексами. Для того, что бы получить доступ к работе с этой сущность через стандартную админку, воспользуемся приложением Пользовательские сущности. Для начала проверим, что приложение установлено. Для этого в админке переходим по адресу /admin/index.php?action=customentity&do=install При переходе по нему, в случае отсутствия необходимых таблиц для работы приложения, они будут созданы. После этого возвращаемся в Редактор форм и в заголовке таблицы czhilkom ищем кнопку со завездочкой Эта кнопка отвечает за создание мини-обработчика для сущности, у которой нет штатного обработчика (в виде встроенного модуля или стандартного\стороннего приложения). NB. Попытка создать этой кнопкой обработчик для встроенных сущностей, как Город, Район или для тех у которых есть приложения - Баннеры, Новости - ни к чему не приведет. После нажатия кнопки Создания обработчика мы увидим следующее окно где в поле Название вам нужно ввести вменяемое название для вашего обработчика, что бы вы знали к чему он относится. Введем например Жилой комплекс и нажмем Создать. После перезагрузки страницы в верху, возле кнопки раскрытия списка приложений мы получим дополнительную кнопку Пользовательские, а под ней и наше квази приложение Жилой комплекс Если перейти по предложенной ссылке, вы получите минималистический инструмент для управления вашими ЖК где вы можете добавить ЖК в список, изменить существующий или удалить ненужный. Приложение не следит за целостностью, т.е. если вы удаляете ЖК, то об удалении соответствующих зависимых корпусов и секций вам так же придется позаботиться самому. Не надейтесь на возможность реализации таким способом каких-то "творческих вывихов" - это исключительно инструмент для обеспечения удобства. Для полноценной работы с такими сущностями, как разделение их по пользователям с возможностью редактирования последними, организация страницы, например конкретного ЖК, шаблонизация необходимо создавать полноценное приложение. Для наших целей добавим два ЖК - Элитный и Морской с помощью кнопки Добавить запись Процесс, как вы можете заметить, вполне привычный и не должен вызвать трудностей 4.1. Корпуса. Создание таблицы корпусов абсолютно ничем не отличается от создания таблицы ЖК кроме того, что у корпусов есть зависимость от ЖК. Например ЖК Элитный имеет два корпуса - Корпус А и Корпус Б. Тогда модель корпуса (ckorps) будет состоять из полей Поле czhilcom_id является обычным полем селектбокса подбирающим данныеиз внешней таблицы, в данном случае из таблицы czhilcom Простыня под спойлером Дальше все по алгоритму - создали таблицу в Редакторе форм, наполнили полями, создали физическую таблицу, зарегистрировали обработчик. Из Пользовательских переходим в Корпуса добавляем Названия сущностей рекомендую давать расширенные - с включением родительского описания. Так как обработчик весьма прост, то особых способов отличить Корпус А от ЖК Элитный и Корпус А от ЖК Морской у вас не будет. В результате мы получаем нечто похожее на

Думаю, что надо сделать универсальное решение - создать справочник регионов, в которых индексы прописать по аналогии налоговых регионов, например 77-Москва, 50-Московская область и т.п., и под эти индексы создавать справочники городов /населенных пунктов региона и улиц, которые можно будет скачивать отдельно и они будут стыковаться с вышестоящими. В принципе, если следовать индексам в КЛАДР, то это получится, там заложена логическая индексация всего вплоть до улиц.

Сделав две недели назад схему для объявлений и авторов объявлений (АН и застройщиков), получил такую статистику загрузки этих данных гуглом: Как видно из данных, гоша неспешно подгружает эти данные - при общем количестве объявлений более 12К, пока с разметкой проиндексировано около 500 шт. В сниппете гугла теперь выводится цена, описание и метка "в наличии" (у нас же все объявления актуальны, воут?) Конечно, большая часть схематичных страниц попала в индекс через аддурилку. Но постепенно, думаю, войдут все. Влияние на ранжирование пока не заметил, сниппеты слега симпатичнее, но над ними еще можно поработать.

Еще один вектор развития, который лично мне, как пользователю, хотелось бы видеть, это интеграция в социальные сети. Первый шаг по сути уже сделан - для пользователей нескольких сетей добавлена возможность быстрой регистрации/авторизации. Но некоторые системы остались за кадром - yandex и mail.ru - а ведь подключив их можно было бы про ручную регистрацию забыть в 99% случаев. Также есть прекрасные задумки про кросспостинг - только реализовано это пока только для twitter, а как было бы прекрасно подключить сюда fb и vk. Снова хочется напомнить про мобильность - конечно, использование бутстрапа и @media позволяет адаптировать сайт к просмотру на мобильном (после некоторых танцев с бубном, правда) и даже Google говорит - Вах, какой адаптированный сайт! Но дело в том, что сайт при этом НЕУДОБНЫЙ. Т.е. его адаптированность сейчас не даёт прироста клиентов (хотя, может и увеличивает ранжирование для мобильных выдач).