[Rodogor]

Пост гнева.

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



Написал в umi, получил ответ:



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

Я очень быстро выяснил, что XML возвращается правильный, режется уже на стороне клиента. (Интересно, а почему не через json, ГЛЮЧИЛО что ли)
Быстро нашёл кучу неиспользуемого кода, кучу левых файлов, в итоге нашёл где это всё делается, поменял... И ничего не заработало. Пол дня матерился - ведь решение рядом, код вот он, больше нигде такого нет.
В итоге показывая заказчику в конце дня результаты мучений офигели от того, что у него РАБОТАЕТ. Оказывается хитро подключенный JS плотно сидел в кеше и даже порнорежим в chrome не спасал. Что бы обновить этот JS файл пришлось открыть его по прямой ссылке и обновить раз 10 пока не появился нужный(обновлённый) кодэ

День потеряна, задача решаемая за пять минут заняла целый день....



Системный код = JS выполняемый на клиентском уровне ?...

[BaceH]

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

по поводу "ядра" респект и уважуха

[Rodogor]

Я тоже думал о таком варианте, но тут два фактора. Один - неудобно перед заказчиком за костыль, второй - все товары импортируются из 1с и если их будет много (а umi ведь хвалятся тем, что потянет огромные объёмы - это я скоро проверю....), то что, все их переименовывать ? Была бы маска какая-то для названий - да не вопрос...
В данном случае выгрузка из 1с 7.7, парсер сам написал. Так вот для импорта цвета и размера договорились в "Наименование" дописывать "Р:31 Ц:Белый", а со своей стороны парсю уже всё и убираю эту подстроку.
Был бы ещё один костыль и в поля с названием уже не хватило бы.

То, что у Вас клиент понимающий проблемы - это здорово.

[Vladimir]

Да, была такая проблема. Пршел к выводу, что ЮМИ здесь винить не за что. Поле "Название" - это не название товара, это некий идентификатор для менеджера, делать их одинаковыми и записывать туда все характеристики товара не следует (тем паче макс. длина 255 символов).
Решалось выделением для длинного названия дополнительного поля.  Поскольку у меня импорт идет из csv, то менеджер просто сразу заносил нужные названия в нужные поля, но, в ином случае, я бы  по событию import_element разбивал название по словам, выбирал первые 3-4 и переименовывал только что импортированный элемент.

По количеству товаров. По моему субъективному опыту начинаются тормоза, когда количество объектов некоего типа (товаров, заказов или пользователей) переваливает за 30 000. Интересно будет узнать как у вас.

[admin]

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