Форум

Возникла необходимость следующего функционала в админке:
[B]создать такое свойство товара (типа "файл"), в котором можно выбрать файл ТОЛЬКО из числа связанных с товаром или его торг.предложениями.[/B]

Что сделано:
- сделал кастом.свойство ( со своим GetPropertyFieldHtml )
- сделал форму выбора картинок (CDialog, запрос картинок аяксом)

... и все бы ничего, но когда данный товар - это одежда с 10 размерами и 20 цветами (по 3-10 картинок в каждом) - в форме выбора картинок одна и та же картинка дублируется по 10 раз (для всех размеров одного цвета).

Понятно, что значит надо почистить список картинок от дубликатов.

ОДНАКО, в документированном АПИ нет такой возможности.
В коде я нашел, как это сделать (в том же CFile::SaveFile все очевидно),
но возникает ощущение, что использовать [B]Bitrix\Main\File\Internal[/B][B]\FileHashTable[/B] и [B]...\FileDuplicateTable[/B] - не совсем норм, даже посредством АПИ, без обращения к БД (особенно на это намекает неймспейс [B]Internal[/B])

[B]Собственно, об этом и вопрос:[/B]
- насколько норм пользоваться [B]FileHashTable [/B]и [B]FileDuplicateTable [/B]в своем коде?

[QUOTE]Евгений Жуков написал:
Наборы надо расширять, но без правок ядра этого не сделать. Так что третий путь.[/QUOTE]
эмм... а почему именно наборы, а не комплекты?

Добрый день.

Есть задача - необходимо на сайте отображать комплекты товаров (например, футболка+сумка); поведение требуется именно такое, как у "комплектов" битрикса (физически товар не существует, доступный остаток формируется из остатков составляющих, при продаже - снижаются остатки составляющих).
[B]НО! [/B]составляющие комплектов существуют в разных цветах и размерах. Соответственно, [B]комплекты - тоже должны иметь признаки "цвет" и "размер"[/B], при этом на сайте посетитель должен иметь возможность в удобном виде менять цвет и размер всего комплекта [B][I](т.е. визуально они должны выглядеть, как обычный товар с торг.предложениями[/I][/B]).

Понятно, что стандартного функционала для этого в битриксе нет (хотя странно, ну да ладно).

[B]Каким, на ваш взгляд, путем будет правильнее идти в данном случае?[/B]

1. Брать за основу товар с торг.предложениями,
к каждому торг.предложению привязывать составляющие товары (через свойства торг.предложения),
а взаимосвязь по остаткам - реализовывать самостоятельно (при изменении остатков составляющих - менять остатки данных "типа-комплектов", и наоборот).

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

3.... третий путь? ...


Мне пока видится менее трудозатратным путь №1 (берем за основу торг.предложения, а связь по остаткам реализуем сами), т.к. 2й вариант повлечеть за собой еще и проблемы с поисковой выдачей и списком товаров в каталоге.

Есть ли другие мнения/идеи?

Заранее спасибо за любые наводки )

[QUOTE]Юрий Колесник написал:
Добрый день!

Не вижу причин, почему вам не сделать закрытый (только для админов) раздел и там уже фильтровать элементы hl блока как вам угодно (под вашу верстку этой формы), и удалять отфильтрованные.  [/QUOTE]

Добрый день.
Тоже вариант, да...
хотя имхо - держать часть админки за пределами админки - немного неуютно для контент-менеджеров будет ))

PS Cвою текущую задачу я решил JS-ом поверх стандартной формы (п.3), но на будущее - по-прежнему интересны рекомендации.

Добрый день.

[B]Есть задача[/B] - модифицировать поведение формы редактирования ХЛ-блока в админке (от значения одних полей - зависят требования к другим полям; как пример - в следующих полях типа "привязка к элементам ХЛ-блока" можно привязать не все элементы связанных ХЛ, а только часть, удовлетворяющих некоторым условиям, которые зависят какраз от значений, заданных в предыдущем поле).

[B]Какие варианты решения рассматриваю:[/B]

1. Кастомный тип поля (чего делать не хочется, т.к. типов полей появится несколько, нужны они только в этой конкретной сущности, а глаза будут мозолить во всех остальных),

2. Кастомная форма редактирования элемента ХЛ-блока -- возможно??  (для ИБ - возможно, это мне известно... а для ХЛ?)

3. Точечное изменение поведения формы редактирования элемента (повешать JS-скрипт, который будет отрабатывать всю логику, но только в случае, если редактируется элемент именно этого ХЛ-блока; плюс своя валидация в **OnBeforeSave). -- костылеобразно, рассматриваю на случай, если п.2 невозможен или слишком трудозатратен.

4. ... есть еще какие-то пути?

[B]Собственно, вопрос:[/B]
- возможен ли п.2 ?
- существует ли п.4 ?

Заранее спасибо )

Добрый день.

Возник вопрос - где допустимо использовать SetViewTarget и AddViewContent?
Гугл дает противоречивые ответы:
1 - в шаблоне нельзя, только в эпилоге (т.к. при кеш-хите они ничего не сгенерируют).
2 - можно и в шаблоне компонента (результаты их деятельности также закешируются отдельно, и при кеш-хите система корректно возьмет их из кеша и отдаст туда, где они нужны ShowViewContent-у)
3 - SetViewTarget можно в шаблоне, AddViewContent - только в эпилоге.

В официальной доке конкретики тоже нет, хотя и приведен пример использования SetViewTarget в шаблоне компонента, что косвенно намекает на то, что ответы 2 и 3 - ближе к правде, а 1 - к неправде (но, опять же, явно об этом ничего не сказано; а про AddViewContent  - вообще ни слова на этот счет).

А известен ли кому-либо вот прям конкретный ответ на этот вопрос? Что из этого все-таки точно можно в шаблоне, а что нельзя?

Заранее благодарю.

[QUOTE]Евгений Жуков написал:
В настройках компонента меню рекурсию включали?[/QUOTE]
эмм... прошу пояснить... речь про какой именно параметр?

Добрый день.

[QUOTE]Евгений Жуков написал:
Определять, была ли картинка, вам нужно только в случае Update. Самый правильный вариант - getList'ом подгять запись из базы и посмотреть - пустое поле или нет....[/QUOTE]
Да, опытным путем пришел к тому же, что наличие файла - надо только в базе проверять (т.к. содержимое поля UF_FILE в Update может вообще не передаваться, если обновление записи делается модулем импорта... это немного странное поведение, если честно, но...).
Более того - существующий файл еще и на консистентность пришлось проверять (т.к. такая же ситуация (отсутствующее поле UF_FILE) возникает при апдейте из админки, в случае, если файл "поломанный" - есть в БД, но нет в папке; и отличить такую ситуацию от "неправильного" обновления из модуля - я возможности пока не нашел).

[QUOTE]Евгений Жуков написал:
...Но только при условии, что меняется поле, содержащее цвет (если, конечно, вы его еще строкой храните).[/QUOTE]
А вот условие "меняется цвет" решил не учитывать (чтобы обеспечить контент-менеджеру возможность принудительной "перегенерации" картинки путем простого удаления старого файла).


[B]НО![/B] "существует ли файл" - это половина вопроса. Вторая половина - "загружается ли новый файл в данном Update". Для этого есть какой-то более правильный путь, чем копаться напрямую в массиве UF_FILE?

Добрый день.
Вопрос от новичка в Битриксе, так что заранее простите ))
но гугл почему-то не смог мне помочь..

[B]Имеем:[/B]
- хайлоад-блок, представляющий цвета торговых предложений (в частности - в нем есть поле [B]UF_FILE [/B]- картинка, представляющая сам цвет).
- настроенный импорт.
[B]Что надо:[/B]
- надо при создании хайлоадов автоматически создавать картинку, представляющую цвет торг.предложения (при создании и обновлении).
- но делать это надо только если пользователь (или модуль импорта) сохраняет хайлоад с пустой картинкой (ну т.е. если он передал картинку явно - сохраняться должна она; если оставил пустой - создаем автоматом).

Соответственно, прежде чем модифицировать данные в событиях [B]OnAfterAdd/OnAfterUpdate[/B], мне надо понять, что происходит с картинкой для данного ХЛ-элемента?
а) ее не было и пользователь/модуль сохраняет с пустой картинкой?
б) ее не было, и пользователь загружает свою?
в) на была в хл-элементе, и ползьователь сохраняет ХЛ без изменений картинки?
г) она была, но пользователь меняет картинку?
д) она была, но пользователь удаляет картинку?
И генерировать новую только в случаях "а" и "д", в остальных - ничего не делать.

[B]В чем, собственно, ВОПРОС:[/B]
- я покопался в данных, которые передаются в события [B]OnAfterAdd/OnAfterUpdate[/B] ( конкретно - в[B] ($event->getParameter("fields"))['UF_FILE'] [/B]), и для себя понял, как определить, что именно происходит с картинкой (в массиве UF_FILE: непустой [B]name/type/tmp_name[/B] - загрузка новой, непустой [B]old_id[/B] - была старая, [B]del==Y[/B] - удаление старой, и т.п.)...
- НО! а нормально ли это, копаться в данных вот так, и полагаться на них? это официально документированная логика? или может есть какое-то правильное API для анализа/модификации данных о загрузке/изменении/удалении файлов в событии?

Заранее спасибо.

[QUOTE]Владимир Быстрыгин написал:
[QUOTE][URL=/community/webdev/user/5396254/]Alexandr X[/URL] написал:
3 разных кеша (по кол-ву разных меню)[/QUOTE]
тогда можно просто сделать 3 разных типа меню и подключать их в компонент в соответствии с урлом )[/QUOTE]
эмм... ну тоже да... но тоже ведь костыль ))
там жеж "интеллектуальный алгоритм кеширования, который учитывет то и это", и вот это всё ))
я просто в битрикс недавно погрузился, и все еще надеялся, что тут изкоробочные механизмы должны делать то, что должны...
не? реальность не так радужна? )))