Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
автор изложил свою картину миру в проекции дерева значений, причем, по моему, ни фига не просто, скорее коряво.
но он имеет право на свою картину мира и как и я на свою.
я бы не рекомендовал эту статью первокурснику по ит.
Субъективно, но все-таки — не люблю, когда слишком увлекаются деревом значений. За пределами интерфейсных задач это вообще бессмысленно, а в интерфейсных зачастую встречаю перегруженность уровнями, когда ради того чтобы добраться до конечных строк нужно долго и упорно эти уровни разворачивать. Т.е. как временно-случайному пользователю такого интерфейса, где попросили что-то подправить, мне это не нравится еще больше, чем как разработчику. По сей причине предпочитаю таблицы значений с отборами, удобнее со всех сторон.
(2) аналогично считаю. Если список большой, то работа с деревом будет сильно тормозить 1с. Лучше всего использовать динамические списки с динамическим считыванием данных
(2) за пределами интерфейсных задачь, есть как минимум одна задача — разузлование изделий, и это реальная боль.
Согласен, что увлекаться глубокими уровнями вложенности не стоит, но интерфесно распределение чего либо: занятость станков, оплаты по реализации, и т.п. очень даж удобно.
(3)а что, в динамическом списке уже можно напрямую ячейки редактировать?
дам пару советов:
— на больших данных не используйте рекурсивный вызов процедур, используйте искуственную рекурсию внутри одной процедуры, для этого нужно два массива, это работает если не на порядок, то в разы быстрее. Кстати в erp2 для разузлования используется рекурсия через две процедуры — это боль.
— для формирования дерева одним запросом используйте СКД с иерархией детальных записей, через связи наборов данных, где делаете связь набора к самому себе
(4) я в свое время эксперементировал и с деревом, и в вложенными таблицами. На данный момент при разработке с чистого листа в том числе для разузлования не стал бы пользоваться деревом. Таблица значений с дополнительными полями, идентифицирующим строки и связи между ними в использовании оказывается много удобнее.
(6) Приветствую. Спасибо за комментарии, с которыми я лично согласен. Они дают больше знаний о дереве и сопутствующих задачах. Статья-то для начинающих, тех, кто знакомится с деревом. Кому-то, мой взгляд на него может оказаться полезным. (1) показался корявым, но я и не претендую на академичность.
На мой взгляд немного некорректно показалось описание метода НайтиСтроки() для коллекции строк:
А как же второй параметр в этом методе, который как-раз таки и определяет возможность поиска с учетом подчиненных коллекций или без них?
В целом, согласен. Есть второй параметр у метода НайтиСтроки(), который позволяет получить и подчинённые строки тоже. Почему о нём не написал? Потому что не было цели скопировать содержимое СП. Я предложил начинающим подход к работе с деревом — получать текущий уровень и работать с ним. Иначе, при использовании второго параметра, придётся разбирать массив строк на текущий и подчинённые уровни. Это тоже вариант, но немного более сложный для понимания. В 1С, вообще, почти всегда есть несколько путей решения задач. Но статья называется «Просто о дереве значений», поэтому я и выбрал более простой, в моём понимании, путь.
И сильно «рекурсивная» НайтиВДереве отличается от «корневой» Дерево_НайтиНаКлиенте? 🙂
(11) Только начальными условиями, стартом с верхнего уровня. Тут простор для творчества широкий, кому как нравится. Эффективность не страдает, читабельность кода, на мой взгляд, повыше.
(12) Я понял. Вопрос был чисто риторический. На мой взгляд, одна функция (может быть даже чуть более развернутая) лучше двух, практически дублирующих друг друга.