Честно говоря ветка комментов далее 4-5 уровня и не уходит :) во всяком случае я редко встречал...
Поэтому в комментах можно выводить сразу все уровни, но... не все комменты.
Сортировку комментов (хватит по карме и дате, а также кол-ву уровней) и paging я советовал бы разработчикам Хабры прикрутить в superhabr
MVC - никто не слышал? 8-\
если сразу начинали программировать на php в школе то может и не слышали.
Скажите это программистам "со стажем" на visual c++ или даже delphi :)
А как же раньше программы делали?
Даже программы расчета з/п, для предприятия с 500 человек работающих, на c++ в досе я делал 14 лет назад по принципам ОOП и MVC и диплом хрен знает когда на с++ защищал по том же принципам.
может тогда MVC понятия и не было, но это не значит что не было контроллеров, модулей, view и их связей... теперь это называется гордо MVC.
Любить не запретишь...:) Любовь зла - полюбишь и ... сами знаете, тем более XMLHTTPRequest... я его тоже любил...но потом извините, это оказался тупиковый путь развития. Забейте на все кодировки и переходите на UTF-8 - будете спать спокойно. И выбирите себе любой fw: будь то jquery, mootoolth, прототайп... чисто человеческий совет. XMLHTTPRequest путь в никуда (сейчас от любителей получу куча минусов - причем 100% не аргументированных а чисто фанатских, но знаю на что иду.. хочу уберечь драгоценное время людей)... я на форуме писал про ошибки ... что-то правилось... но концепция - нет... а это самое главное. Только за один backend и вызов "шапки" (я понимаю для поддержки кодировок...но... UTF-8 жив и живее всех живых) XMLHTTPRequest - не стоит времени на него потраченного...
P.S. Возьмите например jquery - там есть куча хороших библиотек для дерева... например одного моего знакомого http://news.kg/wp-content/uploads/tree/d…
По этому принципу можно и комменты "рулить"
То что система разрабатывалась 10 лет и содержит 2 лимона строк - в этом её главный недостаток...ИМХО.. в один прекрасный момент надо было оставить БРЕНД (маркетологи знают о чем я говорю) и переписать (имея такие человекоресурсы) заново с нуля, согласно новых спецификаций и технологий. Я уверен она бы получилась намного лучше...
А сейчас это какой-то монстр на глиняных ногах....
Просто ломать никто не хотел... код такой запутанный...
и везде где только можно htmlspecialchars... везде... этож надо столько раз эту функцию вызывать ...
А про таскание HTML.= по ядру ... читайте моё продолжение внизу...
ну неужеле немцы не слышали про MVC ? Достаточно на входе контроллера все проверить и "разрулить"...
ну хорошо перестрахуемся... везде на входах M и V и С ... достаточно. Но не в каждом классе и процедуре...
Конечно перестраховаться лучше всего... и запутать (задурить) всех...
Но ведь это сказывается на скорости и на качестве кода для развития другими разработчиками...
Поломать... извините. Стоит просто задасться целью и это вопрос времени.
Вывод: чем запутаней код - тем труднее его сломать :)) , не потому что он не уязвим, а потому что он запутанный и никому нахрен не нужен, чтобы его ломать...
Неплохая CMS?...
Интерфейс и юзабилити админ. части оставляет желать лучшего... извините, но он как и все немцы на вид "деревянный"...
Качество кода - я бы тоже не назвал идеальным, даже хорошим, твердый "банан"? хорошо не "кол", уже у нас так давно никто не делает. А таскание HTML по коду ядра и библиотек!! я бы руки вставлял в зад за такое... $HTML.=$this->wrapIcon('<img'.t3lib_iconWorks::skinImg($this->backPath,$icon,'width="18" height="16"').' alt="" />',$row);
дайте в поиске текста по файлам HTML. и вы всё увидите...
ЭТО чего такое, причем везде такое? !!! Причем в библиотеках!!!! Да за такое, эту CMS на помойку... она создана только для конечных юзеров. Попробуйте что-то поменять... извините слова не подобрал (всем 18 есть? :) ... трахаться будете очень долго...
И так в принципе везде... и вы считаете её хорошей? Я не сторонник Bitrix... далеко, но будем обьективны, до Битрикса ей как до неба раком извините. Битрикс намного интуитевнее, и юзабилити на порядок выше, хоть конечно "перлы" присутствуют, и таскание есть и много чего нехорошего, но все же typo3 не конкурент Bitrix далеко.
Согласен... мало того а где хранить и самое главное зачем? в сессии? уродство... :)
Поэтому стройте дерево на основе level и сортировке сразу при запросе к БД и не заморачивайтесь...
а для ajax-а оставляем div id="parent_..от.." с display:none и добавляем новый коммент туда... с такими же пустыми div и т д
Больше к Apostol:
да и у вас не все понятно, можно поподробнее... где и как и на каком этапе ... тогда можно будет разобрать и ваше решение :)
Есть :) Получать массив ровно такой какой должен быть (block paging желательно с возможность сортировки по карме, дате и т.п. не кто не отменял? а простыню в 200 комментов что читать, что загружать нудно, поверьте разработчики хабры... половину комментов просто игнорируется и читается выборочно, обычно обращается внимание на карму коммента, или все читают до единого коммента?)... далее, я вообще не понимаю зачем что-то обходить и инклудить потом? Ну есть же row['level']... стройте себе дерево... что там инклудить? Модули? Каждый модуль - один раз, потому как ВСЕ данные мы уже получили, и нам надо "расширенные" поля имеющихся УЖЕ данных, которые мы получим обработкой модулей. Не понятно что там инклудить... может темплейт самого коммента? :) ну так тоже... один раз инклуд в память его, и юзайте сколько влезет потом...
Ладно, хорошо, предположу что инклудятся комменты, которые хранятся в дереве файловой системы... но
это простое расточительство ресурсов!... хранить в файловой системе можно и нужно, но только большие страницы... комменты в основном маленькие.... как выход... страницы хранить в файловой системе, а комменты в поле description (потому как у комментов обычно нет description) ноды/страницы/представления или как вы там его еще обозвали в вашей БД.
:))) расмешили. Вы вообще изучали/анализировали алгоритмы "выборки" деревьев....? NS слышали что это такое? Материализованный путь? есть и еще неплохие "коммерческие" алгоритмы для больших "деревянных" БД.
Вот маленький ликбез: http://phpclub.ru/faq/Tree/Ns
Apostol написал...
> Когда пришлось реализовывать дерево комментариев, столкнулся с необходимостью рекурсивного вызова представления (view в MVC)
Зачем рекурсия ... это противоречит концепции MVC.
Получите ВСЕ данные, а потом в View их "разруливайте" ... т.е. получаете выборкой из БД (NS или подобные) ВСЕ данные дерева, где один из параметров будет level (постороить дерево потом это 10 класс средней школы), можете их потом обработать модулями или еще какой-нибудь хренью... и спокойно выводите их ... причем как хотите, и любыми шаблонизаторами...
Вывод: или вы не правильно употребили слово "рекурсия" или что-то не так делаете...
Рекурсия в деревьях - ошибка архитектуры, да и вообще рекурсией никто из специалистов не советует пользоваться... я честно говоря не встречал не в одном серьезном проекте рекурсии... Дерево можно спокойно выбирать и как вы говорите "линейно". NS и кучу других алгоритмов никто не отменял.... вперед дерзайте.
Уважаемый Apostol в 40 лет лет (повелись на ник? это ник моего сына, а их у меня уже 3-е :) ) я провел столько дисскусий и успешных переговоров с инвесторами, что вам скорее всего за ваш возраст (а по статистике здесь в основном возраст от 17 до 24) и не снилось. А вот насчет ошибки (а прогрмамированием, правда как хобби, я занимаюсь 18 лет уже), я её уже чувствую… тем более что я уже закончил свою cms с денормализованной унифицированной иерарархической БД, можно просто сказать как у вас — дерево, и никакой рекурсии там не надо в помине… дерево спокойно можно выбирать «линейно», существуют масса алгоритмов начиная от NS и заканчивая тем что я использовал (средние между NS и материализованным путем).
Поэтому еще раз советую — не занимайтесь хуней (другого слова уже тяжко подобрать, если сразу не понятно, я детей здесь не обидел, всем 18 есть?) Покажите ваш алгоритм, интересно, а вообще у вас есть блок-схема?
Только не надо говорить: конечно есть — сразу в студию…
Кстати слово рекурсия — это слово рекурсия… вы сами писали… и любая выборка в дереве рекурсией заканчивается полной фигней (читаем фактически это ошибка при проектировании «деревянных» БД, начиная от скорости, заканчивая стабильностью)… или кто-то не согласен и хочет получить кучу минусов :) спецы заминусуют сразу?
Очень и очень неплохо...
но.. сегодня
Fatal error: Call to a member function getDescendants() on a non-object in /var/www/nrgn001/demo.energine.org-site/core2a/modules/shop/components/ProductList.class.php on line 44
До шаблонизатора еще дойти надо... там ошибка в контроллере, которая противоречит понятиям MVC.
Если придерживаться концепции MVC, то потом уже, с разруливанием данных, можно лепить что хочешь...
Действительно, ищите просчеты в архитектуре. Никаких рекурсий! , если вы хотите быстрой и СТАБИЛЬНОЙ работы.
Потом будете долго ломать голову, надо какой-нибудь "ошибкой"... а ошибка может быть очень малозаметная, например утечка памяти.
Однозначно переделывайте архитектуру пока не поздно...
Полностью согласен.
Вот вам результат, и то что я писал выше подтверждается...
Поэтому в комментах можно выводить сразу все уровни, но... не все комменты.
Сортировку комментов (хватит по карме и дате, а также кол-ву уровней) и paging я советовал бы разработчикам Хабры прикрутить в superhabr
см. снизу продолжение...
если сразу начинали программировать на php в школе то может и не слышали.
Скажите это программистам "со стажем" на visual c++ или даже delphi :)
А как же раньше программы делали?
Даже программы расчета з/п, для предприятия с 500 человек работающих, на c++ в досе я делал 14 лет назад по принципам ОOП и MVC и диплом хрен знает когда на с++ защищал по том же принципам.
может тогда MVC понятия и не было, но это не значит что не было контроллеров, модулей, view и их связей... теперь это называется гордо MVC.
P.S. Возьмите например jquery - там есть куча хороших библиотек для дерева... например одного моего знакомого http://news.kg/wp-content/uploads/tree/d…
По этому принципу можно и комменты "рулить"
А сейчас это какой-то монстр на глиняных ногах....
и везде где только можно htmlspecialchars... везде... этож надо столько раз эту функцию вызывать ...
А про таскание HTML.= по ядру ... читайте моё продолжение внизу...
ну неужеле немцы не слышали про MVC ? Достаточно на входе контроллера все проверить и "разрулить"...
ну хорошо перестрахуемся... везде на входах M и V и С ... достаточно. Но не в каждом классе и процедуре...
Конечно перестраховаться лучше всего... и запутать (задурить) всех...
Но ведь это сказывается на скорости и на качестве кода для развития другими разработчиками...
Поломать... извините. Стоит просто задасться целью и это вопрос времени.
Вывод: чем запутаней код - тем труднее его сломать :)) , не потому что он не уязвим, а потому что он запутанный и никому нахрен не нужен, чтобы его ломать...
Интерфейс и юзабилити админ. части оставляет желать лучшего... извините, но он как и все немцы на вид "деревянный"...
Качество кода - я бы тоже не назвал идеальным, даже хорошим, твердый "банан"? хорошо не "кол", уже у нас так давно никто не делает. А таскание HTML по коду ядра и библиотек!! я бы руки вставлял в зад за такое...
$HTML.=$this->wrapIcon('<img'.t3lib_iconWorks::skinImg($this->backPath,$icon,'width="18" height="16"').' alt="" />',$row);
или это
$HTML.='=<span style="color:red;">'.$this->wrapValue($theValue,$depth).'</span>';
...
дайте в поиске текста по файлам HTML. и вы всё увидите...
ЭТО чего такое, причем везде такое? !!! Причем в библиотеках!!!! Да за такое, эту CMS на помойку... она создана только для конечных юзеров. Попробуйте что-то поменять... извините слова не подобрал (всем 18 есть? :) ... трахаться будете очень долго...
И так в принципе везде... и вы считаете её хорошей? Я не сторонник Bitrix... далеко, но будем обьективны, до Битрикса ей как до неба раком извините. Битрикс намного интуитевнее, и юзабилити на порядок выше, хоть конечно "перлы" присутствуют, и таскание есть и много чего нехорошего, но все же typo3 не конкурент Bitrix далеко.
Вывод: пусть немцы и ебуться с ней
Поэтому стройте дерево на основе level и сортировке сразу при запросе к БД и не заморачивайтесь...
а для ajax-а оставляем div id="parent_..от.." с display:none и добавляем новый коммент туда... с такими же пустыми div и т д
да и у вас не все понятно, можно поподробнее... где и как и на каком этапе ... тогда можно будет разобрать и ваше решение :)
Есть :) Получать массив ровно такой какой должен быть (block paging желательно с возможность сортировки по карме, дате и т.п. не кто не отменял? а простыню в 200 комментов что читать, что загружать нудно, поверьте разработчики хабры... половину комментов просто игнорируется и читается выборочно, обычно обращается внимание на карму коммента, или все читают до единого коммента?)... далее, я вообще не понимаю зачем что-то обходить и инклудить потом? Ну есть же row['level']... стройте себе дерево... что там инклудить? Модули? Каждый модуль - один раз, потому как ВСЕ данные мы уже получили, и нам надо "расширенные" поля имеющихся УЖЕ данных, которые мы получим обработкой модулей. Не понятно что там инклудить... может темплейт самого коммента? :) ну так тоже... один раз инклуд в память его, и юзайте сколько влезет потом...
Ладно, хорошо, предположу что инклудятся комменты, которые хранятся в дереве файловой системы... но
это простое расточительство ресурсов!... хранить в файловой системе можно и нужно, но только большие страницы... комменты в основном маленькие.... как выход... страницы хранить в файловой системе, а комменты в поле description (потому как у комментов обычно нет description) ноды/страницы/представления или как вы там его еще обозвали в вашей БД.
Вот маленький ликбез: http://phpclub.ru/faq/Tree/Ns
> Когда пришлось реализовывать дерево комментариев, столкнулся с необходимостью рекурсивного вызова представления (view в MVC)
Зачем рекурсия ... это противоречит концепции MVC.
Получите ВСЕ данные, а потом в View их "разруливайте" ... т.е. получаете выборкой из БД (NS или подобные) ВСЕ данные дерева, где один из параметров будет level (постороить дерево потом это 10 класс средней школы), можете их потом обработать модулями или еще какой-нибудь хренью... и спокойно выводите их ... причем как хотите, и любыми шаблонизаторами...
Вывод: или вы не правильно употребили слово "рекурсия" или что-то не так делаете...
Поэтому еще раз советую — не занимайтесь хуней (другого слова уже тяжко подобрать, если сразу не понятно, я детей здесь не обидел, всем 18 есть?) Покажите ваш алгоритм, интересно, а вообще у вас есть блок-схема?
Только не надо говорить: конечно есть — сразу в студию…
Кстати слово рекурсия — это слово рекурсия… вы сами писали… и любая выборка в дереве рекурсией заканчивается полной фигней (читаем фактически это ошибка при проектировании «деревянных» БД, начиная от скорости, заканчивая стабильностью)… или кто-то не согласен и хочет получить кучу минусов :) спецы заминусуют сразу?
но.. сегодня
Fatal error: Call to a member function getDescendants() on a non-object in /var/www/nrgn001/demo.energine.org-site/core2a/modules/shop/components/ProductList.class.php on line 44
Если придерживаться концепции MVC, то потом уже, с разруливанием данных, можно лепить что хочешь...
Потом будете долго ломать голову, надо какой-нибудь "ошибкой"... а ошибка может быть очень малозаметная, например утечка памяти.
Однозначно переделывайте архитектуру пока не поздно...