« Rev
@evolutioncms   899
Fwd »


Pathologic
через магический метод __call
Dmytro
Нет
Dmytro
Будет метод parseChunk Который будет делать return $this->tpl->parseChunk;
Pathologic
ну и смысл такого разделения тогда
Dmytro
В том что не будет файла на 7 тыс строк
Dmytro
Или сколько у нас их там
Anonymous
Там не 7 тысяч
Anonymous
Там по моему 6400
Dmytro
А будет до 1000
Anonymous
6763
Dmytro
И потом легче все будет + доку перепишем на Использование нормальных методов через tpl->
Anonymous
Ты был ближе
Dmytro
И в одной из версим старые обьявим деприкейтед а потом удалим
Сергей
нас и так не любят за быструю систему, так теперь ещё и бить на улице начнут))
Dmytro
Ибо делать сразу не получиться
Pathologic
в случае с магическим методом строк еще меньше будет ((:
Anonymous
Вот я не уверен, что не буду тем человеком который не будет вас бить за деприкейт
Dmytro
в случае с магическим методом строк еще меньше будет ((:
Магию можно заюзать но надо тестить что будет быстрее да и надо начать с систематизации ибо скопипастить с 1 файла в другой не сложно
Pathologic
в целом тут получится хуже чем с дитто, потому что дитто можно обновить, а сайты где много самописного говнокода просто так не обновишь
Dmytro
Что б вместо 1 х 6763 было 10 по 680
Dmytro
Что куда удобней дебажить и работать с гитом ;) и не будет проблемы что кодемиррор вешает ;))
Dmytro
По факту вся ооп в том что б вместо 1 файла сделать 10+ ;))
Dmytro
Для того что б разделить и упорядочить и тд Грасп солид и все такое
Pathologic
Сергей понадобилось загрузить 151 класс чтобы я вызвал три функции ((:
Dmytro
Это ооп ;))
Pathologic
я к тому, что не нужно пытаться экономить на спичках
Pathologic
это как в машине трястись над миллилитрами бензина
Anonymous
это как в машине трястись над миллилитрами бензина
а потом начинается, давайте в каждую библиотеку по 10 копий одного пакета.
Pathologic
понятно, что до такого тоже доводить не нужно ((:
Anonymous
А где-нибудь можно этот анализатор кода так в личных целях использовать?
Anonymous
Тот же что у гитхаба
Pathologic
можно наверное за деньги
Anonymous
А то вот фиг поймёшь, я поправил этот свой говнокод который ухудшил показатель или не поправил
Pathologic
там может ругаться на длинный метод или сложное условие
Anonymous
Я нажал в phpstorm ctr+alt+l и всё стало ещё хуже
Anonymous
Так что сейчас откатился на ту версию что была. И поправил только свой говнокод
Сергей
Я нажал в phpstorm ctr+alt+l и всё стало ещё хуже
а не указал наверное что PSR2 хотелось бы использовать?
Сергей
снифер нверное поставил, композер, для правильного форматирования?
Сергей
правила установил.. включил их использование?
Anonymous
правила установил.. включил их использование?
Скорей всего в этом и есть мой косяк
Aliaksandr
Еще не хватало все на modx api перевести:)
Anonymous
Да, даёшь везде голый mysqli_query, API не нужно
Aliaksandr
Если разница в скорости раз в сто, то можно и так:)
Aliaksandr
Но modx->db вполне справляется
Aliaksandr
Я был бы только за апи, но то, что нынешнее непригодно для использования в массовых операциях это факт, на который невозможно закрыть глаза или отмахнуться
Pathologic
так у тебя редкий случай
Pathologic
да и в целом, за удобство нужно ж чем-то платить
Anonymous
Скажу честно, для больших данных в evo много что не подходит.
Anonymous
Например по дефолту myisam. Если массово обновлять, то innodb в разы выигрывает.
Anonymous
Так же modResource маловероятно делался под то что будут грузить туда туеву тучу данных, а делался скорее для упращения изменения ресурсов
Pathologic
ну, в modResource и прочих есть сомнительные места
Pathologic
но задачи ж выполняются
Anonymous
Я вот не люблю когда всё завязано на инкриментное значение. Тогда нельзя в базу сразу записать 100 000 записей😁
Anonymous
Точнее можно, но вдруг что пойдёт не так
Pathologic
да, со всякими менюиндексами много геморроя
Anonymous
Но это укор не evo, а многим cms где всё завязано на определённую структуру данных. Они никогда не бывают достаточно гибкими под все задачи
Anonymous
Полностью под всё не подстроишься
Pathologic
поэтому пришла пора что-нибудь поломать
Aliaksandr
Мечта поэта edit->set->save(), даже думать не надо, против может быть только такой отморозок как я:)
Aliaksandr
А чтоб один документ создать сохранить, то тут конечно проще)
Aliaksandr
Лучше б энергию не на опровержение очевидного направить, а на поиск того места, что жрет ресурсы, вот тогда б была песня
Aliaksandr
А то никто толком не знает на 100% как оно работает до конца, но все знают, что это круть:)
Pathologic
так а что ты предлагаешь?
Pathologic
убирать проверки всякие?
Aliaksandr
Так же modResource маловероятно делался под то что будут грузить туда туеву тучу данных, а делался скорее для упращения изменения ресурсов
Тем более, что я вчера как раз и говорил, что я не совал в него эту тучу данных, а просто изменял pagetitle, а вот зачем он сам в себя эту тучу насовал неоднократно и что он с ней очень долго делал, неясно))
Aliaksandr
убирать проверки всякие?
Я до конца там логику так и не понял, на decodeFields ->encodeFields у меня сдали нервы:)
Anonymous
поэтому пришла пора что-нибудь поломать
Не надо ломать, а то потом точно буду щемить всех. И меня первым, за то что я подталкиваю ко всему
Pathologic
decodeFields и encodeFields это для полей с json
Aliaksandr
Я же при импорте тоже все проверяю, но это не жрет столько времени
Pathologic
в modResource наверное еще для тв с ||
Aliaksandr
Последнее что было, это то, что в edit у меня осталось пять нужных мне тв, но в save снова вылезло 2000 и они вписались пустыми. После этого у меня случился аффект))
Pathologic
опять начинается
Pathologic
не могут они быть пустыми
Aliaksandr
У меня были:)
Aliaksandr
Я то думал, что если в edit делается ->store, то в save оттуда и берется. А нифига
Pathologic
все фига
« Rev
@evolutioncms   899
Fwd »