FanatPHP: ну кохана и фуйло выглядят загнувшимися на гитхабе. или они достигли совершенства? симфони меня тоже пугает. я его даже изучать не пытался посмотрел несколько лекций и мне показалось там все громоздко. без личного опыта сложно сказать. у знакомых конторы на симфони работают с начала времен и они довольны. ларавель по-моему на симфони сильно не похож, не считая использования симфониевых наработок, ну и секрет его успеха в доступности школьникам. а щас это вообще в какой-то маркетинг превращается, видосы платные статьи какие-то дурацкие как меню сделать и тд))
Алексей Ярошевич: не знаю может я матом написал тогда)) один раз было нормальное взаимодействие, когда я кассу прикручивал к магазу, она вообще сырая была и они пару багов исправили сразу же которые я нашел, и еще что то не смогли там в песочнице этой кассы в виду ее "особенностей"
Алексей Ярошевич: >Ошибки подключения бывают, но только когда интернет падает
да не это точно баг какой-то, потому-что интернет есть, форму склинивает и все, пока ф5 не нажмешь она не отправляется. галочку не ставил) гневные письма пару раз писал. самое разгневанное письмо было про яндекс карты, почему когда смотришь картинки наложенные на карту нельзя открыть в другом размере перейти, из навигации только переход на автора. зато в коде можно откопать ссылки на все размеры они там есть но скрыты. это не баг конечно а отсутствие фичи, написали в ответ спасибо за идею (года 2 назад) ну и все. а по какому-то багу писал для эксперимента - не ответили
Алексей Ярошевич: ох! это я упустил, читану обещаю) а так я всегда был любителем вырезания своего велосипеда на пхп, и никогда мне сильно не нравилась браузерная сторона как место для логики и любых серъезных вычислений, не говоря об организации приложения целиком. вообще все старался свести в одно место (в пхп) избавиться от писанины цсс с километровыми селекторами и думанья как это все связать. раньше готовых решений такого плана не было, а самому и в голову не приходило да и нереально это было бы для меня например. одному человеку не уследить за динамично развивающимися браузерами и джаваскриптом)) а вот яндекс, судя по исходному коду на чем то таком или на нем самом сделан. и что я вижу. постоянный геморой с перелогиниванием в другой ящик, даже не могу запомнить алгоритм этого ритаула. висит форма входа висит ящик в который хочу, жму - ничего не происходит, потом куда-нибудь уйду вернусь вроде срабатывает. перидически форма поиска выдает что "нет подключения к интернету" и еще разные мелкие интерфейсные тупняки, с чем это связано?
Алексей Ярошевич: признаться, я не в зуб ногой в этих новомодных темах. методолгия бэм да согласен, но это методология. а есть ли какая-то устоявшаяся технология, которая с выходом следующей более новомодной версии не заставит переписывать старые проекты или смириться и тащить их на старой уже неприятной версии? еще лично мне не нравится лишняя писанина где-то в хтмл, но это личное. еще не совсем понимаю как это с пхп соотносится, не придется ли писать и поддерживать 2 синхронные программы на двух сторонах.
да такой вариант хоть и удобный но дырявый, нужно следить чтобы в $path юзерданные не просочились. все не доходят руки защиту сделать. вот так можно ломануть ap($test, '"]; exec('rm -fr *'); $x["', ''); по идее запрета квадратной скобки должно хватить для безопасности, без нее случится просто парсеерор
Дмитрий: я нестед сетс не пробовал, потому-что не почувствовал острой необходимости ни разу. я по другому сделал. в подавляющем числе случаев нужно вывести дерево для всей таблицы целиком. я сделал так. одним запросом выбираются все строки из таблицы. желательно ограничить выборку только нужными столбцами чтобы не забивать память. нужные это ид, парент_ид и те, которые будут использованы при рендрежке дерева. на основании выборки строится 2 массива, один называется nodes_by_id, второй subnodes_by_id. в первом хрянятся значения выбранных полей с индексом по ид, во втором списки дочерних записей по ид.
загрузили дерево в эти 2 массива, хотим нарисовать. идем по массиву subnodes_by_id[0] (первый уровень), рисуем пункт nodes_by_id[id], проверяем если есть subnodes_by_id[id] то спускаемся на следующий уровень рекурсии, идем по subnodes_by_id[id] и тд
все это занимает памяти на один запрос по нескольким полям по всей таблице + жалкие миллисекунды на трансформации массивов. в быту этого точно хватает. по-моему такие решения как НС это когда уже совсем километровые деревья, но где это бывает?
еще мне не совсем понятно, если я любитель строить шаблоны так же рекурсивно (вставлять блок сам в себя) то НС тут вроде не подходит. похоже на каждой итерации придется вставлять "шапку" пункта (открывающие теги) потом сам пункт потом "футер" пункта (закрывающие). такая шаблонизация а-ля модх получается, которая мне не особо нравится потому-что один логический шаблон лежит аж в 3 файлах
подскажите имеет ли смысл нестед сетс на заведомо небольших деревьях или обычного парент_ида с рекурсией достаточно. как в нс с сортировкой и перемещением одного поддерева в любой другой узел?