Возвращаясь к теме переопределения структуры — тут вопрос не такой острый, и, пожалуй, это самое простое и быстрое решение. Поэтому пулл-реквест приму, со статусом «экспериментального» (до лучших времен, когда этот вопрос будет решен другими метдами, или потребует изменения кода).

`cot_load_structure_custom()` практически не вариант, т.к. на момент вызова `cot_load_structure()` еще не сработал ни один основной хук и нам просто негде подключить кастомную ф-ю. Единственная возможность это файл `functions.custom.php` при включенной опции `$cfg['customfuncs']`.

Скорее всего этот вариант наиболее простой на данный момент.

Основная проблема при работе со стандартной функцией cot_load_structure() это невозможность получить список подкатегорий не прибегая к перебору всей структуры снова и снова.

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

Добавлено 1 неделя спустя:

#41475 Macik:
`cot_load_structure_custom()` практически не вариант, т.к. на момент вызова `cot_load_structure()` еще не сработал ни один основной хук и нам просто негде подключить кастомную ф-ю. Единственная возможность это файл `functions.custom.php` при включенной опции `$cfg['customfuncs']`.

Возможно ли добавить замену внутри функции на cot_load_structure_custom() как это сделано с функцией cot_mail? 
И если да, то будет ли эта возможность добавлена до релиза 0.9.19?

Добавлено 1 день спустя:

Уважаемые разработчики, посмотрите мой pull request.

Добавил замену функции на cot_load_structure_custom().

Еще вариант это хранить предков в отдельной сущности или чилдренов.. я использую разные подходы, в зависимости от нужд скрипта..

Хук тоже хорошее решение. Все остальное можно под себя реализовать в зависимости от сложности проекта. Спасибо!

Еще как вариант не плохо бы иметь возможность полностью заменить функцию cot_load_structure() на cot_load_structure_custom() при ее наличии.

«Возвращайся сделав круг…»

1. Хук внутри функции у нас имеется — `structure`. Но это проблема, для структур в несколько тысяч записей, т.к. директива `include`в таком цикле может легко скушать несколько секунд.
2. `cot_load_structure_custom()` практически не вариант, т.к. на момент вызова `cot_load_structure()` еще не сработал ни один основной хук и нам просто негде подключить кастомную ф-ю. Единственная возможность это файл `functions.custom.php` при включенной опции `$cfg['customfuncs']`.

Ваши мнения? 

Ну это уже совсем неприемлимо) 

Конечно, ни тот ни другой из озвученных здесь способов не идеальны, всегда будет что-то чем придётся жертвовать. 

Лично мое мнение, структура не должна быть частью ядра. Но раз уж так завелось, то хотелось бы, чтобы ее применение было более гибким.

Еще как вариант не плохо бы иметь возможность полностью заменить функцию cot_load_structure() на cot_load_structure_custom() при ее наличии.

Говорим об памяти и быстродействии и пихаем обьект ? Я конечно не спец в этой области но кажется мешать ООП и то что есть не самая лучшая идея.  Или отказываться в котонти от легкости и переходить на полноценный ООП а то будет шопопало имхо 

Я бы не был так категоричен. Мнение, что объекты или ООП в целом, это медлено и жрет память, то же самое что сказать, что массивы в ПХП не оптимальны и потребляют от 80 до 140 байт на описание одного элемента. Это правда. Но вопрос в том, как это использовать...

Если каждую запись делать объектом, да еще поиметь оверхед на инициализацию и прочее — то да, это как раз пример «ООП это тормоз и жрет память».

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

Мы же используем сейчас объекты для доступа к БД, кеша, шаблонов. Потому, что при грамотной реализации это удобнее в использовании и оптимальнее с точки зрения кода.

---

Резюмируя...

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

Возможно сейчас, как «быстрое решение», имеет смысл добавить хуки в cot_load_structure() .

В целом согласен с Esclkm в том, что текущая реализация не оптимальна и нуждается в переарботке.

Я считаю, что все аспекты работы со структурой должны быть перенесены в объект

#41260 esclkm:

 

надо сделать в виде класса

Говорим об памяти и быстродействии и пихаем обьект ? Я конечно не спец в этой области но кажется мешать ООП и то что есть не самая лучшая идея.  Или отказываться в котонти от легкости и переходить на полноценный ООП а то будет шопопало имхо 

Если вариант не подходит, то как минимум предлагаю прописать хуки в cot_load_structure(), чтобы не приходилось постоянно писать костыли под свои задачи.

Вроде все так, но не так. Увеличился объем занимаемой памяти самой структуры.

При этом от рекурсии мы не избавились? я про то, что дочерние, дочерних, что с ними?

Скорость - об этом тоже ни слова. Плюс почему исправление только в load_structure? что с get_children?

Я считаю, что все аспекты работы со структурой должны быть перенесены в объект

А информация о детях и их родителях в массиве в объекте

Предлагаю добавить в генерируемый массив категорий значение subcats, в котором будет формироваться массив подкатегорий для конкретной категории. Опыт использования такого подхода в сборке фриланс-биржи показал хорошие результаты. 

Код измененной функции cot_load_structure() можно посмотреть тут: https://github.com/cmsworksru/cot-freelance/blob/52ce4f903035abef8c90d431f1e695a9f8617fd7/system/functions.php#L1197

В частности добавлены следующие строки: 

https://github.com/cmsworksru/cot-freelance/blob/52ce4f903035abef8c90d431f1e695a9f8617fd7/system/functions.php#L1233
https://github.com/cmsworksru/cot-freelance/blob/52ce4f903035abef8c90d431f1e695a9f8617fd7/system/functions.php#L1278-L1284