28 мая 2013 в 6:13
Как известно на сайте АН могут быть разные типы недвижимости (квартиры, дома и т.д)
Их нужно как-то хранить, фильтровать.
Часть полей у них общая, часть отличается.
Хочется попробовать реализовать это через сущности.
Вот и думаю..
Возможно ли будет создать структуру используяECK? Нужно ли будет программировать?
Удобно ли будет админить через IEF
Может использовать Commerce? Там удобно создаются сущности.
Комментарии
ECK из админки не позволяет управлять урлами созданых сущностей.
Думаю, в вашем случае вполне достаточно будет обынченых нод.
Сейчас тоже разрабатываю подобный проект и задумываюсь над сущностями. В принципе ноды со всеми задачами справляются (можно использовать дополнительные модули для скрытия лишних полей, если они не нужны в квартирах или земле, например), но возникает проблема, если требуется сделать некотрые поля обязательными для заполнения. Например, в "квартирах" есть поле "общая площадь" в кв.м., а в "земле" есть поле "площадь участка" в сотках. Так вот если скрыть обязательное поле "общая площадь" при выводе формы в "земле", то получится ошибка.
Получается, лучше сделать несколько сущностей под каждый вид недвижимости? Да и гибче это будет. Здесь вопрос не в простоте создания сайта, а в его качестве.
Проще реализовать хук_ентити_инфо и хук_схема, все будет намнооого прозначней. И думаю что если на сайте понадобится поиск по большому числу критериев (найти однокомнатные квартиры в кирпичных домах в Ленинском районое ценой до 2500тр не на 1м этаже) то лучше сразу отказываться от "друпал-вей" (напихать 100500 полей в ноды) а делать все ручками.
Можно (и нужно) делать разные типы нод и аттачить к ним разные поля.
Я, конечно, еще только разбираюсь с сущностями, но логика мне видится такой:
есть сущность "недвижимость", содержащая в себе общие поля для всех видов недвижимости (адрес, цена и т.д.) и есть бандлы (или сущности?) содержащие уникальные поля для каждого вида недвижимости.
deb, вы советуете не заморачиваться с сущностями, а сделать все на нодах?
Программировать скорее всего нужно будет в любом случае.
Вполне себе подойдут и ноды. Интерфейс администрирования уже есть, с views всё работает отлично, можно ставить модуль search_api и реализовывать нормальный поиск на сайте. Со своими типами сущностей думаю придётся повозиться, что бы всё это отладить.
Если есть много полей, которые можно сгруппировать по какому-то признаку, то нужно смотреть на их заполняемость. Вполне можно сгруппировать некоторые данные таким образом, что бы хранить их как отдельное поле (с точки зрения поля ноды). Например любое помещение характеризуется адресом. Адрес можно хранить как одним полем, в котором хранится просто строка: г.Новосибирск, ул. Пупкина, д.9, и т.д. Или разбить адрес на несколько полей: город, улица, номер дома, корпус, квартира и т.д. Дальше, если вы прикрутите к ноде отдельные поля, в которых хранится только части адреса, то кол-во таблиц в базе у вас вырастет прилично (на одно поле ноды, 2 таблицы в базе), и всякие там выборки будут работать неэффективно, потому, что запросы будут выглдеть примерно так:
INNER JOIN ...
INNER JOIN ...
INNER JOIN ...
INNER JOIN ...
INNER JOIN ...
...
INNER JOIN ...
WHERE 1
. Поэтому можно создать собственный тип поля cо своими виджетами, и способами вывода. При этом все составляющие поля ноды будут храниться в одной таблице БД (двух, если учесть наличие revision). Смотрите как это сделано в модуле examples/field_example
Можно конечно и сущности собственные создать. Но, мне кажется, в поставленном вами вопросе нет ничего, что бы говорило о необходимости плодить новые сущности (возможно это от неполноты предоставленной вами информации).
Создайте столько типов материала, сколько вам нужно.
Используйте общие для них поля.
Создавайте собственные составные поля.
Что мешает не создавать в ноде 100500 полей, а объединить первые 100 полей в одно, и остальные 500 ещё в пять других по каким-то характерным признакам.
Я на разных типах материла уже делал.
Теперь задумался о том что бы к ноде приатачивать сущность определенного типа (bundle).
Есть вариант создать масштабируемое решение.
Но видимо с сущностями много возни..
Сущности несомненно являются лучшим решением в некоторых ситуациях. Но, не всегда можно справиться скальпелем там, где нужен топор (возможно не самая удачная аналогия:)).
Через ноды значительно быстрей, но правильней имхо было бы писать кастомный код. Мне кажется плохой идеей хранить характеристики недвижимости типа площади, этажа, цены и т.п. в полях друпала. Было бы правильней хранить это в своей отдельной табличке. Ну а чтобы получить все ништяки, предоставляемые сущностям в Друпале, достаточо реализовать hook_entity_info.
Я про кастомный код и говорю.
Предположим я создаю разные типы материалов для каждого вида: Продам квартиру, сдам комнату, куплю землю и т.д. База разрастется очень сильно. Как тогда для пользователя создать единую форму где он будет из выпадающих списков выбирать вид недвижимости (квартиры, земля...) и вид сделки (куплю, продам, ...)? Соответственно нужно выводить нужный тип материала.
А если мне необходимо сделать возможность импорта объявлений агентствам недвижимости, например, из файла и подцеплять картинки к объявлениям? По-моему, в этом случае работать со своими таблицами и своей структурой. Или это тоже можно решить на уровне нод?
Ситуация в том что разных типов недвижимости процентов 70-80% полей (характеристики объекта) одинаковые, остальные разные.
Получается плодить прийдется: хоть типы, хоть сущности, хоть составные поля.
Думаю в последних здесь меньшего всего смысла.
kv4, с адресом как раз такой проблемы нет.
Географию я думаю решать иерархической таксономией, гипотетически начиная со страны и заканчивая улицей, ниже не нужно.
deb, согласен. только еще не делал, и не представляю какой там объем работ работы.
Хук напишешь. А как редактировать, виджет отображения автоматом не появится?
Связать со views нужно?
Админить поля через код? Нужно писать в админку.
Можно ли хоть ли совместить кодинг и использования ECK, например?
Просто я уже делал 1 подобный проект и использовал всего 1 тип материала с множеством полей. 60к объектов недвижимости, а БД весит более 1,5 ГБ. Скорость работы сайта оставляет желать лучшего
Вот и задумался написать кастомный код используя сущности... но пока не знаю с какого бока к ним подойди
Saltan, не нужно создавать тип "продам квартиру". Нужно создавать тип "квартира" и поле "вид операции".
Но и так реализовать универсальную форму добваления не получится. И заимпортить с помощью feeds все сразу тоже не получится. Без кодинга.
Даже в таком виде есть разные поля в случае покупки квартиры и сдачи в аренду. Так что такой способ тоже не очень подходит.
Форму создания/редактирования придётся сделать руками (всё кроме полей)
Чтобы связать со Views достаточно указать какой-то ключ в hook_entity_info
Админить через код не надо, этим занимается модуль Field
Не знаю, ECK не пользовался.