А можно уточнить что именно? После диагонального чтения доки, я только увидел класс Factory, который напоминает Laravel где за фасадом прячется (да я в курсе что это фабрика)
А когда Yii стал сложным? Ничего вам не мешает поднять на Yii REST API где будут контроллеры, AR и собственно все.
У меня есть такое ощущение, что CI не дотягивает до "больших" дядек (Yii, Symfony, Laravel), но уже не такой "маленький" (Slim, Lumen, Silex), и поэтому вообще не понятно зачем он нужен.
Ну а его простота даёт ему скорость по сравнению с другими PHP фреймворками
Из-за простоты, или есть бенчмарки? Если простота = скорость (что в целом логично), то возьмите Slim для REST, он отлично справится, да к тому же еще проще и еще легче. Зачем в этой ситуации CI тогда?
Поскольку документация написана хорошим, технически понятным языком, то в процессе ознакомления с этим и другими разделами возможно получить даже некоторое эстетическое удовольствие.
А у кого плохим? Как по мне любой популярный фреймворк (Yii, Symfony, Laravel, Zend) имеет хорошую и понятную документацию. Для Yii она еще и на русском по большей части. Чем CodeIgniter принципиально отличается своей документацией?
В CodeIgniter 4 есть практически всё, что требуется при разработке современного web-проекта практически любой сложности
А у кого нет? Миграции, Роутинг, DAO, ORM, MVC реализацию есть у всех фрейморков. У Yii например есть готовые докер файлы которые просто запускаются и работают. Есть serve сервер. Что есть у CI?
Но есть один момент, который возможно будет решён в CodeIgniter 5, нет возможности сразу получить целиком «рабочий пример» из «Installation» или «Command Line»
А вы точно пытались? Там вроде все просто (на примере CLI):
Тезисы: определите KPI (как пример 2 невероятные метрики), нанимайте правильных людей (вообще без комментариев), Создавайте подкоманды (единственный абзац по теме), Выберите правильную модель (дак как ее выбрать и какую?!)
Небольшой вопрос: где эта самая структура-то?! Я понимаю что это перевод, но он в целом нахер такой он не нужен, где тупо рекламная портянка без какой-либо конкретики (кстати надо бы тэг "я пиарюсь" добавить).
Я лишь озвучил то, что сначала был WS, а в результате стал JS.
Сначала был JS и использование WS, а потом остался только JS, т.е. отказались от WS. Таким образом весь вывод можно оформить так: «Проблемы с нагрузкой были из-за использования сокетов». Зачем тут нужно приплетать JS и фреймворки, которые в данной ситуации вообще ни на что не влиют?
Я никого не призываю отказываться от framework'ов. Я выражаю свое мнение, что порой новое это не всегда то, что вам нужно. Что и показал здесь реальный пример из практики и не более того.
Опять все в кашу. При чем тут фреймворки и что-то новое?
Логика только в том, что бы прежде чем использовать новый framework, лучше его сначала изучить и понять как он работает. Подумать подходит ли он под ваши требования, что бы потом в спешке не пришлось его менять.
Это да, соглашусь, вот только из вашего вывода вообще это не следует. Следует что нужно выкинуть все фреймворки, а использовать pure js и будет счастье. Хотя дело далеко не в этом. И в тех же самых фреймворка есть как минимум готовые инструменты для кеширования (это если говорить про бэк).
В вашем примере глубоко пофиг какой используется frontend фреймворк, у вас проблема с нагрузкой бэка, а не отрисовкой фронта. Так что все таки вывод неверный на счет javascript.
В свете динамических развивающихся framework’ов (react, angular, node, sping и др.), не всегда стоит их применять для разработки продуктов
А где логика? В вашем примере все уперлось в постоянно открытый сокет, а не фреймворк или язык. И так на минуточку «JS фреймоврк» — это тоже «javascript». Видимо ваша стизя тестирования, в программирование лезть не стоит :)
Для большей полезности могли бы описать какие инструменты использовали, мне как не искушенному в тестировании человеку очень интересно :)
1. Странное требование (скорее всего не так сформулировано), но тем не менее вы фактически показываете только ограниченное число элементов (те что входят на страницу) и для конченого пользователя без разницы загружено все 100 элементов, а видит он только 20 или загружено 20 элементов и он эти 20 элементов видит.
2. не понял о чем речь, не хватает контекста, но не суть
3. эээ а в чем проблема? Компонент выводит кнопку, при нажатии вызывается что-то вроде parent.$store.dispatch('viewEditModal', item);. Компонент всплывающего окна находится вне таблице и «слушает» $store. Сеньор помидор в азбуке вкуса должен знать такие простые конструкции :)
Что делает разработчик, когда сталкивается с проблемой? Идет гуглить.
Неплохо бы сначала подумать, чтобы хотя бы правильный запрос в гугл отправить :)
И парочка вопросов:
1. зачем выводить по 100 строк на 1 страницу, если можно разбить на более мелкую пагинацию и все будет ок?
2. Судя по 14К компонентам, у вас 100 строк и 140 столбцов. Не кажется ли слишком большим число столбцов, и проще/лучше было подумать про «горзинтальную пагинацию» чем грузить все подряд?
3. Не знаю как в Nuxt (не работал с ним), но во Vue есть функциональные компоненты, которые как раз для таких случаев и нужны: внутри ячейки у вас легкий функциональный компонент, который при нажатии на кнопки (видимо удаление, редактирование, добавление) пушат в store информацию и отображается компонент ВНЕ таблицы? Это не поможет с количеством компонентов внутри таблицы, но явно облегчит саму таблицу.
4. Можно было сделать авто-пагинацию, когда доскролил до нижней границы текущей страницы, подгружать автоматом след страницу, когда докрутил до верхней границы пред-страницы
В чем заслуга mail.ru и чему у них учится? Контент не их, они его перевели.
Ну хотя о чем это я, ты ж любитель говна на вентилятор накидать :) Это я про «Другим промоблогам надо учиться»
Как и в первой части пример слишком простой, и нет понимания «А зачем делать отдельный класс для 1 html тэга?». Вот если бы пример выглядел как-то так:
Что-то похожее на код
$renderer = new Renderer($settings);
// добавить цепочечных вызовов, чтобы можно было строить такии конструкции
$menu = (new Menu)
->setTemplate('header')
->setItems([
'Main' => '/',
'About' => '/about',
// ...
]);
$renderer->append(new Header)
->append($menu)
->append(new LoginForm)
->setViewedFields('login', 'password');
$article = $renderer->append(new Article);
$article->setContent('...');
$article->setOpenGraph([
'author' => 'Mike',
'created' => '2021-05-24',
]);
$renderer->append(new Footer)
->append(new SubscribeForm)
->withCaptcha()
->append(clone $menu)
->setTemplate('footer');
echo $renderer->render();
Понятно, что в конце репозитории в которые заходишь и непонятно за что схватиться, куда смотреть и чем наслаждаться :)
А вообще кстати вопрос (в первый раз это упустил): допустим у меня есть блок Menu и естестственно у меня есть меню в шапке и в подвале, содержимое и правила отображения (внутренняя логика) у них одинаковое, а вот шаблоны разные. Каким образом можно переиспользовать блок? Наследоваться и создавать новый класс с новым шаблоном?
Дак любой проект, на любом фреймворке расширяем благодаря composer. Это вообще не заслуга CI.
А можно уточнить что именно? После диагонального чтения доки, я только увидел класс Factory, который напоминает Laravel где за фасадом прячется (да я в курсе что это фабрика)
А когда Yii стал сложным? Ничего вам не мешает поднять на Yii REST API где будут контроллеры, AR и собственно все.
У меня есть такое ощущение, что CI не дотягивает до "больших" дядек (Yii, Symfony, Laravel), но уже не такой "маленький" (Slim, Lumen, Silex), и поэтому вообще не понятно зачем он нужен.
Посмотрите Yii db , вообще с ума сойдете :D
Из-за простоты, или есть бенчмарки? Если простота = скорость (что в целом логично), то возьмите Slim для REST, он отлично справится, да к тому же еще проще и еще легче. Зачем в этой ситуации CI тогда?
А у кого плохим? Как по мне любой популярный фреймворк (Yii, Symfony, Laravel, Zend) имеет хорошую и понятную документацию. Для Yii она еще и на русском по большей части. Чем CodeIgniter принципиально отличается своей документацией?
А у кого нет? Миграции, Роутинг, DAO, ORM, MVC реализацию есть у всех фрейморков. У Yii например есть готовые докер файлы которые просто запускаются и работают. Есть serve сервер. Что есть у CI?
А вы точно пытались? Там вроде все просто (на примере CLI):
Далее создаете контроллер и запускаете его через:
В чем не "рабочесть" данного примера?
Тема не раскрыта о слова совсем. Могли бы хотя бы заявленный функционал засунуть в статью, а то вникать в структуру CI если никогда с ней не работал - нет смысла, а для информации было бы интересно (наверное). Если конечно там что-то новое и отличающееся от документации: https://codeigniter.com/user_guide/dbmgmt/migration.html и https://codeigniter.com/user_guide/dbmgmt/seeds.html
Сейчас это уже не анекдот, а объюзивные отношения :)
Заголовок: Структура службы поддержки клиентов
Тезисы: определите KPI (как пример 2 невероятные метрики), нанимайте правильных людей (вообще без комментариев), Создавайте подкоманды (единственный абзац по теме), Выберите правильную модель (дак как ее выбрать и какую?!)
Небольшой вопрос: где эта самая структура-то?! Я понимаю что это перевод, но он в целом нахер такой он не нужен, где тупо рекламная портянка без какой-либо конкретики (кстати надо бы тэг "я пиарюсь" добавить).
Судя по комментариям выше у меня у одного код в статье как дерьмо отображается: без переносов, без отступов и с великолепной [ ` ] ?
Сначала был JS и использование WS, а потом остался только JS, т.е. отказались от WS. Таким образом весь вывод можно оформить так: «Проблемы с нагрузкой были из-за использования сокетов». Зачем тут нужно приплетать JS и фреймворки, которые в данной ситуации вообще ни на что не влиют?
Опять все в кашу. При чем тут фреймворки и что-то новое?
React и Vue — разные подходы. Symfony/Laravel и Yii — разные подходы.
Так что нет, они плюс минус одинаковые на первый взгляд.
Нет, конечно, решит все проблемы правильная архитектура и правильное использование технологий. Только где об этом речь?
Это да, соглашусь, вот только из вашего вывода вообще это не следует. Следует что нужно выкинуть все фреймворки, а использовать pure js и будет счастье. Хотя дело далеко не в этом. И в тех же самых фреймворка есть как минимум готовые инструменты для кеширования (это если говорить про бэк).
В вашем примере глубоко пофиг какой используется frontend фреймворк, у вас проблема с нагрузкой бэка, а не отрисовкой фронта. Так что все таки вывод неверный на счет javascript.
А где логика? В вашем примере все уперлось в постоянно открытый сокет, а не фреймворк или язык. И так на минуточку «JS фреймоврк» — это тоже «javascript». Видимо ваша стизя тестирования, в программирование лезть не стоит :)
Для большей полезности могли бы описать какие инструменты использовали, мне как не искушенному в тестировании человеку очень интересно :)
2. не понял о чем речь, не хватает контекста, но не суть
3. эээ а в чем проблема? Компонент выводит кнопку, при нажатии вызывается что-то вроде
parent.$store.dispatch('viewEditModal', item);. Компонент всплывающего окна находится вне таблице и «слушает» $store. Сеньор помидор в азбуке вкуса должен знать такие простые конструкции :)Неплохо бы сначала подумать, чтобы хотя бы правильный запрос в гугл отправить :)
И парочка вопросов:
1. зачем выводить по 100 строк на 1 страницу, если можно разбить на более мелкую пагинацию и все будет ок?
2. Судя по 14К компонентам, у вас 100 строк и 140 столбцов. Не кажется ли слишком большим число столбцов, и проще/лучше было подумать про «горзинтальную пагинацию» чем грузить все подряд?
3. Не знаю как в Nuxt (не работал с ним), но во Vue есть функциональные компоненты, которые как раз для таких случаев и нужны: внутри ячейки у вас легкий функциональный компонент, который при нажатии на кнопки (видимо удаление, редактирование, добавление) пушат в store информацию и отображается компонент ВНЕ таблицы? Это не поможет с количеством компонентов внутри таблицы, но явно облегчит саму таблицу.
4. Можно было сделать авто-пагинацию, когда доскролил до нижней границы текущей страницы, подгружать автоматом след страницу, когда докрутил до верхней границы пред-страницы
Ну хотя о чем это я, ты ж любитель говна на вентилятор накидать :) Это я про «Другим промоблогам надо учиться»
Понятно, что в конце репозитории в которые заходишь и непонятно за что схватиться, куда смотреть и чем наслаждаться :)
А вообще кстати вопрос (в первый раз это упустил): допустим у меня есть блок Menu и естестственно у меня есть меню в шапке и в подвале, содержимое и правила отображения (внутренняя логика) у них одинаковое, а вот шаблоны разные. Каким образом можно переиспользовать блок? Наследоваться и создавать новый класс с новым шаблоном?