topic_id select_box_structure Можно ли его заменить на более адекватное отображени?

[ipr25 0]

Добрый день! Есть один нюанс с формой подачи объявления 

 

В форме DATA графа ТИП

 

По умолчанию стоит select_box_structure и выглядит для пользователя все это добро таким образом

•  Аренда
• . . Комнаты
• . . Гостинки
• . . 1-комн.
• . . 2-комн.
• . . 3-комн.
• . . 4-комн.

 

 

Естественно это крайне не удобно для пользователя сайта отсюда вопрос

Можно ли заменить ее чем нибудь без последствий?

Чтобы к примеру в одном окне пользователь выбирал тип сделки (пример : аренда)

В другом выбирал тип помещения

 

Так чтобы меню , формы поиска и прочие связанные функции не слетели?

 

 

Может есть какие другие варианты решения данной проблемы?    если ставить просто select_box структура не выводится

[abushyk 694]

Чтобы к примеру в одном окне пользователь выбирал тип сделки (пример : аренда)

В другом выбирал тип помещения

 

Да. Для этого тип контракта выводится из структуры, в которой остаются только значения типизации недвижимости - квартира, дом, офис, etc

А под тип контракта заводится отдельное поле, обычно это select_box с системным именем optype со значениями 1 - Аренда, 2 - Продажа. Это поле поддерживается механизмом поиска.

 

 

Так чтобы меню , формы поиска и прочие связанные функции не слетели?

 

 

Тут нужно смотреть конкретно каждые "меню и прочие связанные функции". Поле с системным именем optype умеет учитываться в поиске. Т.е. его остается просто добавить на форму поиска. В меню, если речь он навигационном списке под апкой, который строится на основании значений структуры, то оттуда оно пропадет. Что такое "остальные связанные функции" я пока не знаю.

[ipr25 0]

Да. Для этого тип контракта выводится из структуры, в которой остаются только значения типизации недвижимости - квартира, дом, офис, etc

А под тип контракта заводится отдельное поле, обычно это select_box с системным именем optype со значениями 1 - Аренда, 2 - Продажа. Это поле поддерживается механизмом поиска.

 

Теперь еще больше запутался) Поюзаю форум может есть инструкция)

[abushyk 694]

http://barcelona-comfort.com/add

 

поле Тип операции кодирует ТОЛЬКО тип операции

поле Тип должно было кодировать исключительно тип недвиги (как будто в этом селекте выкинуть корневые пункты Продажа, Аренда, а оставшиеся дочерние оставить только разные). Но тут владелец оставил - ему так удобнее было с навигашкой.

 

А вот второй пример

http://an-pdm.ru/

 

тут тип операциии никоим образом не фигурирует в списке типов. и это отображено прямо на форме поиска.

[ipr25 0]

 

 

А вот второй пример

http://an-pdm.ru/

 

тут тип операциии никоим образом не фигурирует в списке типов. и это отображено прямо на форме поиска.

 

 

Второй пример идеален для меня)

Но боюсь без посторонних не разберусь

 

Как я понял нужно в форме DATA ТИП (тип сделки) topik_id  пока не знаю каким образом оставить Родительские категории

 

Ниже создать тип недвижимости и указать optype  для того чтобы учитывался на поиске

 

Все верно?

 

И как себя поведет основное меню при такой замене?

[abushyk 694]

Представьте себе, что сейчас 15 век и вы знатный работорговец. Вы решили запилить портал по продаже рабов.

Вы же не будете делать Структуру в виде

Высокие- Блондины- - зеленые глаза- - голубые глаза.....- Брюнеты- - зеленые глаза- - голубые глаза..........Низкие - Блондины- - зеленые глаза- - голубые глаза.....- Брюнеты- - зеленые глаза- - голубые глаза..........

Вы, скорее всего, создадите свойства отдельные по росту, цвету глаз, волос и т.д., что бы избежать громоздкого и повторяющегося в ветвях дерева. Так и с недвигой. Есть отдельное свойство тип (квартира, дом) и тип контракта (продажа. аренда). Он не влияют друг на друга. Напрямую. Принципиально вероятность сдачи в ареду например участка земли маловероятна, но она имеет место быть. Так и с любой другой парой этих свойств. Именно из-за это нет никакого смысла бъединять их в одно свойство в рамках структуры.

 

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

 

Как я понял нужно в форме DATA ТИП (тип сделки) topik_id  пока не знаю каким образом оставить Родительские категории

 

 

Нет. Нужно сформировать список пунктов, которые будут описывать именно типизацию недвижимости в чистом виде, без примесей типа сделки.

 

Ниже создать тип недвижимости и указать optype  для того чтобы учитывался на поиске

 

 

Да. При чем именно с таким набором значений, как я написал выше. (1 - Аренда, 2 - Продажа)

[XTRO 154]

Представьте себе, что сейчас 15 век и вы знатный работорговец.

хороший пример

лет 5 назад сыну объяснял третье правило нормализации, вот бы тогда этот пример )))

[ipr25 0]

Представьте себе, что сейчас 15 век и вы знатный работорговец. Вы решили запилить портал по продаже рабов.

Вы же не будете делать Структуру в виде

Высокие- Блондины- - зеленые глаза- - голубые глаза.....- Брюнеты- - зеленые глаза- - голубые глаза..........Низкие - Блондины- - зеленые глаза- - голубые глаза.....- Брюнеты- - зеленые глаза- - голубые глаза..........

Вы, скорее всего, создадите свойства отдельные по росту, цвету глаз, волос и т.д., что бы избежать громоздкого и повторяющегося в ветвях дерева. Так и с недвигой. Есть отдельное свойство тип (квартира, дом) и тип контракта (продажа. аренда). Он не влияют друг на друга. Напрямую. Принципиально вероятность сдачи в ареду например участка земли маловероятна, но она имеет место быть. Так и с любой другой парой этих свойств. Именно из-за это нет никакого смысла бъединять их в одно свойство в рамках структуры.

 

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

 

 

Нет. Нужно сформировать список пунктов, которые будут описывать именно типизацию недвижимости в чистом виде, без примесей типа сделки.

 

 

Да. При чем именно с таким набором значений, как я написал выше. (1 - Аренда, 2 - Продажа)

 

 

Да пример то нагляден и понятен, как это должно быть я понял.   

Но единственный момент который для меня пока еще не понятен это как оставить в select_box_structure (которая нужна для вывода структуры)  только значения типизации недвижимости

 

Встряли нужно править структуру через 

/admin/?action=structure

 

Ведь тогда придется править и меню и формы (а я пока новичок и только разбираюсь в Sitebill) 

 

Можно ли обойтись меньшей "кровью"  и вывести в select_box_structure только типизацию недвижимости без правки кода (может есть какая заветная команда внутри шаблона формы)

 

Пробовал через {key~~value}  но видимо select_box_structure рассчитан исключительно под вывод всей структуры и с этой опцией не дружит...(

[ipr25 0]

Думаю разобрался будем переделывать структуру, и разбираться как связать ее с меню и поиском((