Leaderboard

Я хочу завести в базу клиента -покупателя. и чтобы определенные параметры его запроса - являлись фильтром базы квартир! таким образом, чтобы после добавления клиента, программа формировала список подходящих ему объектов, а я в свою очередь могла бы удалять или добавлять еще их. Таким образом для каждого клиента будет сформирован "подбор" по которому уже свободно распечатав- можно побежать на показы. Есть какое-то реальное предложение по этому поводу? или может есть готовый модуль?

Продолжаю отдельными постами, так как исчерпал лимит на картинки в одном сообщении )) 4.1. Секции. Не буду давать расширенного описания, скажу только, что все идентично как для корпусов. Таблица csection и поля csection_id, name, ckorps_id (по таблице ckorps) В принципе для секций можно было бы установить двойную зависимость - указывать принадлежность секции к корпусу и к ЖК. Для некоторых случаев это оправдано (особенено если делается полноценное приложение), но в нашем случае, когда необходимо лишь поразграничивать принадлежности и сам корпус и ЖК будет указан в свойствах недвижимости, такая связка будет избыточной. В итоге 5. Внедрение в недвижимость Сущности у нас готовы, можно приступать к привязке их на объявление. Нам необходимо добавить три свойства в нашу таблицу data - ЖК, Корпус и Секция. Все они будут добавляться полями типа select_by_query, что бы мы могли сформировать их списки в элементах выбора из соответствующих таблиц. Носить имена будут эти элементы czhilcom_id, ckorps_id и csection_id Если теперь мы перейдем в форму добавления объявления мы увидим, что наши новые три поля уютно прописались в форме в виде привычных списков выбора. Но если их поразворачивать, то вы увидите, что они вмещают все варианты из своих таблиц и не реагируют на состояние "родительского" элемента. Например выбор ЖК никак не отражается на содержимом списка корпусов. Приступаем к наладке связей. 6. Связывание Основой для связывания служит принцип связанных элементов формы - 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 Нам необходимо в рамках одной формы указать элементам на какие другие элементы они влияют в форме и от каких зависят. Например - ЖК. От состояния этого элемента зависит возможный список выбора в элементе Корпуса. Эта зависимость описывается какЭто значит, что элемент, в котором мы выбираем название ЖК связан с элементом с системным именем ckorps_id (элемент выбора Корпуса ЖК), а ключем, который внутри Корпуса соответствует жилому корпусу является значение из поля czhilcom_id модели Корпуса. Если взлянете выше, то это значение в модели Корпуса у нас является идентификатором ЖК, к которому привязан Корпус.Больше ЖК у нас ни на что не влияет, потому и других параметров нет. Далее Корпус. Корпус, аналогично ЖК влияет на "следующий" элемент - Секцию. Но, кроме этого, он еще должен знать от какого элемента зависит сам - это необходимо для формирования адекватного списка значений элемента Корпус, но не тогда, когда сделан выбор конкретного ЖК, а при загрузке формы. Например, если вы открыли на редактирование объявление в котором ЖК был указан как Элитный, тогда в списке Корпусов вполне ожидаемо окажется уже готовый список корпусо ЖК Элитный. linked - описывает зависмость когда элемент влияет на что-то.depended - когда что-то влияет на элемент И, наконец, Секция. Самый простой элемент. Он ни на что не влияет, но на него влияет Корпус. Что и видно из параметров. Нет ничего страшного, если вы ничего не поняли про связи с первого раза. Это нормально, Я гарантирую это. Если теперь вы попробуете загрузить форму добавления объявления, вы видите, что у вас доступен на выбор только элемент ЖК, а остальные будут подгружены только после выбора соответствующего родительского. Для того, что бы увидеть этот эффект в Настройках необходимо включить параметр Настройки - Дополнительно - Off system Ajax 7. Эпилог Ай, у меня не работают элементы выбора географии. Что делать?... Тут все ожидаемо. Изначально принцип связанных элементов предназначался как-раз для географических элементов, что бы вывести из кода движка жесткие зависимости Страна-Регион-Город-Район\Улица и иметь более широкую возможность настройки своих связей. А так же, иметь возможность введения промежуточных элементов (Страна-Регион-Субрегион-Город), которые разрывали бы существующие связи, заложенные в код Сайтбилля. Именно поэтому опция Off system Ajax отрубает всю систему заложенных связей. Возможно это слишком кардинально и стоило бы предусмотреть ступенчатую систему, когда подключение пользовательских связанных элементов регулировалось бы одной настройкой, а отключение привычной связки от Страны к Улице другой. На данный момент четкого мнения у меня пока нет. Для себя я решил эту проблему навеской связей на географические элементы в виде, аналогичном системным правилам. Т.е.country_idlinked region_id,country_id region_idlinked city_id,region_iddepended country_id city_idlinked street_id,city_id;district_id,city_iddepended region_id district_idlinked mkrn_id,district_iddepended city_id street_iddepended city_id mkrn_iddepended district_id 8. Offtop С другой стороны, даже этот способ немного избыточен. Если Город является дочерним к Региону, а Регион к Стране, то хранение всех трех значений для объявления - это "лишние" данные, хотя при организации поиска они весьма кстати. Суть в том, что географические данные вполне возможно хранить в виде, схожем со структурой и получать к ним доступ более "человечным" путемНо в этом случае остается так же много вопросов связанных с совместимостью с многими приложениями, принципом организации смой геоструктуры (ведь если заструктурить географию от страны до улиц - это может стать неподъемным грузом, а если закончить городом, то не совсем понятно, как вести связь дальше к улицам, которые должны таки быть привязаны к городам или чему-то наследному от них). В общем идея у нас полно, была бы возможность все реализовать)