Если у вас возникли какие либо вопросы которые вы не смогли решить по нашим публикациям самостоятельно,
то ждем ваше обращение в нашей службе тех поддержки.
Итак, каждый товар имеет свой тип - это привязка к другому инфоблоку, в котором будут храниться характеристики. Тут все просто, делаем одно поле типа привязка к инфоблоку и называем ее "Тип товаров", а второе поле будет стандартной привязкой к элементам инфоблока и назовем его "Связанное описание товара". Первая вкладка формы будет выглядеть так:
Теперь сделаем вторую вкладку. Вторая вкладка - это характеристики товара, на ней выводится набор полей, определенных в инфоблоке, который был указан в качестве типа товара. Получается, что на этой форме происходит редактирование сразу двух элементов из разных инфоблоков: товар и его характеристики. Хотя на самом деле там еще несколько инфоблоков есть, но это уже другая тема.
Специально вставил форму побольше от ноутбуков, чтобы было видно дополнительную группировку характеристик.
Теперь немного объясню, как это работает. При создании нового товара заполняется форма на первой вкладке и второй вкладке. Первая вкладка сохраняется в том же инфоблоке, где идет редактирования, а вторая сохраняется в инфоблоке, который указан в свойстве "Тип товара". При отправке формы происходит обычное сохранение данных и мы получаем ID нового товара. Также мы получили характеристики этого товара в массиве $_POST - создаем новую запись в инфоблоке с характеристиками и делаем в нем мнемонический код равный ID товара. Получаем ID записи с характеристиками и записываем в свойство привязки товара к характеристикам. Таким образом получается двусторонняя связка "характеристики <--> товар".
В принципе, на форме товара свойство с привязкой показывать не обязательно, а лучше вообще скрыть от администратора, а то еще выберет что-нибудь ненужное.
Есть еще такая проблема - вкладка с характеристиками показывается, если установлено значение типа товара. Т.е. чтобы появилась вкладка, надо отправить форму со значением типа товара. Проблема была частично решена установкой дефолтного типа товаров для разделов через пользовательские поля. Допустим, есть у нас раздел "Жесткие диски", в его пользовательских полях есть свойство "Тип товара" - точно такой же список связанных инфоблоков. Теперь, когда товар создается в разделе, то тип товара устанавливается автоматически из пользовательского поля раздела и вкладка с характеристиками видна сразу. В принципе, можно было бы даже ограничиться определением типа товара на уровне раздела, а не для каждого элемента, но такое решение мне кажется более гибким. Разумеется, у разделов тип товара наследуемый. Если "Жесткие диски" - раздел первого уровня, то и на всех вложенных разделах работает установка типа товара.
Теперь порассуждаю немного о целесообразности данного подхода. Есть некоторые преимущества.
1. Весь товарный каталог в виде одного инфоблока. В этом инфоблоке есть все необходимые свойства товара именно как ТОВАРА. Для администратора такое представление достаточно понятное.
2. Интеграция с 1С проще, когда все товары в одном инфоблоке.
3. Можно сделать разделы разных типов на разных уровнях. И даже товары разных типов в пределах одного раздела. Например, часто встречаю интернет-магазины, где в разделе ноутбуков есть раздел сумок для ноутбуков.
Из минусов конечно же усложнение всей логики интернет-магазина, сортировки по свойствам, формы. Но эти проблемы уже более-менее решены.
Ну еще немного расскажу о других вкладках данной формы.
Описание - на ней я объединил поля "Описание для анонса" и "Полное описание". В стандартной форме они разнесены на отдельные вкладки. При этом описание для анонса я сделал поменьше, всего в 5 строк.
Фото - туда вынесены детальное фото и дополнительные фотографии (обычно это свойство называют MORE_PHOTO). Фото для анонса я не использую, так как почти везде оно генерируется из детального фото.
Отзывы - список отзывов по данному товару. Тут по сути тоже привязка к другому инфоблоку. Ну ведь это удобней админу сразу проверить отзывы в товаре, чем идти в другой инфоблок, там сделать фильтр по ID нужного товара. А тут все сразу. Отзывы тоже не простые, в них помимо текста есть еще оценка по 4 характеристикам, является ли автор отзыва владельцем товара, рекомендует ли товар другим, плюсы и минусы товара. Все это выводится на этой вкладке. Администратор может удалять или редактировать отзывы.
Прочее - туда вынесены разделы и все дополнительные поля: сортировка, код, символьный код, тэги. Опять же потому что мне так показалось удобней. По большому счету на эту вкладку админу ходить незачем - раздел установлен выбором папки в структуре ИБ, символьный код генерируется автоматически для новых элементов. Ну если только указать дополнительные разделы.
Назад в раздел
то ждем ваше обращение в нашей службе тех поддержки.
Довожу до ума форму редактирования товаров
Задача - сделать для администратора интернет-магазина нормальную форму добавления / редактирования товара. Учитывая то, что в моем интернет-магазине характеристики товаров вынесены в отдельные инфоблоки, задача немного усложняется. Под нормальной формой я понимаю такую форму, в которой всё расположено рядом и удобно для редактирования.Итак, каждый товар имеет свой тип - это привязка к другому инфоблоку, в котором будут храниться характеристики. Тут все просто, делаем одно поле типа привязка к инфоблоку и называем ее "Тип товаров", а второе поле будет стандартной привязкой к элементам инфоблока и назовем его "Связанное описание товара". Первая вкладка формы будет выглядеть так:
Теперь сделаем вторую вкладку. Вторая вкладка - это характеристики товара, на ней выводится набор полей, определенных в инфоблоке, который был указан в качестве типа товара. Получается, что на этой форме происходит редактирование сразу двух элементов из разных инфоблоков: товар и его характеристики. Хотя на самом деле там еще несколько инфоблоков есть, но это уже другая тема.
Специально вставил форму побольше от ноутбуков, чтобы было видно дополнительную группировку характеристик.
Теперь немного объясню, как это работает. При создании нового товара заполняется форма на первой вкладке и второй вкладке. Первая вкладка сохраняется в том же инфоблоке, где идет редактирования, а вторая сохраняется в инфоблоке, который указан в свойстве "Тип товара". При отправке формы происходит обычное сохранение данных и мы получаем ID нового товара. Также мы получили характеристики этого товара в массиве $_POST - создаем новую запись в инфоблоке с характеристиками и делаем в нем мнемонический код равный ID товара. Получаем ID записи с характеристиками и записываем в свойство привязки товара к характеристикам. Таким образом получается двусторонняя связка "характеристики <--> товар".
В принципе, на форме товара свойство с привязкой показывать не обязательно, а лучше вообще скрыть от администратора, а то еще выберет что-нибудь ненужное.
Есть еще такая проблема - вкладка с характеристиками показывается, если установлено значение типа товара. Т.е. чтобы появилась вкладка, надо отправить форму со значением типа товара. Проблема была частично решена установкой дефолтного типа товаров для разделов через пользовательские поля. Допустим, есть у нас раздел "Жесткие диски", в его пользовательских полях есть свойство "Тип товара" - точно такой же список связанных инфоблоков. Теперь, когда товар создается в разделе, то тип товара устанавливается автоматически из пользовательского поля раздела и вкладка с характеристиками видна сразу. В принципе, можно было бы даже ограничиться определением типа товара на уровне раздела, а не для каждого элемента, но такое решение мне кажется более гибким. Разумеется, у разделов тип товара наследуемый. Если "Жесткие диски" - раздел первого уровня, то и на всех вложенных разделах работает установка типа товара.
Теперь порассуждаю немного о целесообразности данного подхода. Есть некоторые преимущества.
1. Весь товарный каталог в виде одного инфоблока. В этом инфоблоке есть все необходимые свойства товара именно как ТОВАРА. Для администратора такое представление достаточно понятное.
2. Интеграция с 1С проще, когда все товары в одном инфоблоке.
3. Можно сделать разделы разных типов на разных уровнях. И даже товары разных типов в пределах одного раздела. Например, часто встречаю интернет-магазины, где в разделе ноутбуков есть раздел сумок для ноутбуков.
Из минусов конечно же усложнение всей логики интернет-магазина, сортировки по свойствам, формы. Но эти проблемы уже более-менее решены.
Ну еще немного расскажу о других вкладках данной формы.
Описание - на ней я объединил поля "Описание для анонса" и "Полное описание". В стандартной форме они разнесены на отдельные вкладки. При этом описание для анонса я сделал поменьше, всего в 5 строк.
Фото - туда вынесены детальное фото и дополнительные фотографии (обычно это свойство называют MORE_PHOTO). Фото для анонса я не использую, так как почти везде оно генерируется из детального фото.
Отзывы - список отзывов по данному товару. Тут по сути тоже привязка к другому инфоблоку. Ну ведь это удобней админу сразу проверить отзывы в товаре, чем идти в другой инфоблок, там сделать фильтр по ID нужного товара. А тут все сразу. Отзывы тоже не простые, в них помимо текста есть еще оценка по 4 характеристикам, является ли автор отзыва владельцем товара, рекомендует ли товар другим, плюсы и минусы товара. Все это выводится на этой вкладке. Администратор может удалять или редактировать отзывы.
Прочее - туда вынесены разделы и все дополнительные поля: сортировка, код, символьный код, тэги. Опять же потому что мне так показалось удобней. По большому счету на эту вкладку админу ходить незачем - раздел установлен выбором папки в структуре ИБ, символьный код генерируется автоматически для новых элементов. Ну если только указать дополнительные разделы.
Назад в раздел
Подписаться на новые материалы раздела:
