попробую его вручную в x86_64-efi поставить

Чак Норрис не может проиграть

Не, не помогло. Половина вообще всего, что пытаюсь установить на этом падает. Придётся действительно систему грохнуть.

Хотя докер вот установился, может в нём заработает)

Первая ссылка в гугле https://ubuntuforums.org/showthread.php?t=2327343

Первая ссылка в гугле https://ubuntuforums.org/showthread.php?t=2327343

Мне почему-то не попалось. Так или иначе пишу с новенькой системы (за одно на ssd её поставил), экспериментирую с hginx + php-frm

Хм. Теперь с php всё ок, установил юзи заново, vendor опять нет. Композер всячески потеребил, не помогло :(

composer -vvv install и лог на гист

Вы, люди, слышали о таких вещах, как Докер или Вагрант. На кой леший убивать систему?

О докере слышал и хотел даже заюзать, но решил что буду разбираться с этим дольше чем хотел бы

composer -vvv install и лог на гист

https://gist.github.com/0x9d8e/664422a7b453d55210f0cc6311a9431e

https://gist.github.com/0x9d8e/664422a7b453d55210f0cc6311a9431e

не устанавливается же

плагин нужен

для yii2

Всем привет! Есть философский вопрос. Как лучше возвращать из метода/функции путь к директории? со слешем на конце или без? Например: /dir1/dir2/ или /dir1/dir2, какой вариант лучше?

По-моему, без. Ведь каталог — это тоже типа файл.

Зависит от использования, но кажется есть стандарт на эту тему

Всем привет! Есть философский вопрос. Как лучше возвращать из метода/функции путь к директории? со слешем на конце или без? Например: /dir1/dir2/ или /dir1/dir2, какой вариант лучше?

я всегда со слешем возвращаю. теоретически в URL без слеша это файл, со слешем директория.

Это откуда такая теория?

ну типа в 1998 году браузеры без слеша не понимали, что им надо искать директорию :)

лан это шутко. браузеры конечно тут не причем

я тоже со слешем добавляешь потом имя файла и получаешь полный путь, если имя файла в переменной, то канкатенировать слеш не нужно

Зависит от использования, но кажется есть стандарт на эту тему

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

нафига везде добавлять черту, если ее можно по дефолту задать?

Если вывести $_SERVER, то можно увидеть, что все пути не содержат черту в конце.

Слеш это разделитель. Логично что сервер паф не содержит его

Если конфигурировать базовый путь, то удобней его со слешем указывать для последующей конкатенации со значениями

именно так и имел ввиду

В конфиге MODX все пути с чертой.

Хм.

да это чисто соглашение разработчиков

как "не подключаться напрямую к БД, а использовать наш супер класс"

Наверное, да, дело вкуса.

Добрый день

Ку

хочу сайт на yii2 из localhost перенести в Vagrant. Цель основная отдать заказчику сайт , чтобы он его у себя локально запустил. Ну и чтобы потом было его удобно перенести на сервер(взять образ и его и поставить на сервер)

окей.

держи нас в курсе

как правильнее сделать ? я вот на сайте https://puphpet.com делать думал образ.но может быть уже есть готовый образ (со всеми нужными модулями и настройками), на убунту чтобы я уже в нем изменения сделал и его и использовал

=)

https://github.com/yiisoft/yii2-app-advanced/blob/master/docs/guide/start-installation.md нашел =|

Мы используем Docker

спасибо за наводку, ищю инфо

Такой вопрос: есть какие-то проблемы с композером (или с руками, не могу сказать ибо не юзал его прежде), так что мне будет быстрее юи руками из архива поставить. Но. Не приведёт ли это к тому, что каждое расширение мне придётся тоже ставить руками?

Такой вопрос: есть какие-то проблемы с композером (или с руками, не могу сказать ибо не юзал его прежде), так что мне будет быстрее юи руками из архива поставить. Но. Не приведёт ли это к тому, что каждое расширение мне придётся тоже ставить руками?

Докер же ты ставил? Заюзай https://github.com/schmunk42/docker-yii2-app-basic

или даже лучше поставить docker-compose и вот эту штуку от тех же авторов: https://github.com/dmstr/docker-yii2-app

Докер же ты ставил? Заюзай https://github.com/schmunk42/docker-yii2-app-basic

На другую систему) Спасибо, попробую. Вернее сейчас пытаюсь вручную поставить весь тот список пакетов, с которым у композера беда (может будет какая польза от такого экспириенса), а докер мне потом в любом случае потребуется.

В общем я сам себе негодяй безглазый. В логе он требовал ext-dom, по которому гуглится php-xml. Установил и дело пошло.

Я в yii новичок (и вообще в популярных фреймворках), гляжу на gii и думаю. Допустим сгенерил он мне нужные классы. Я их дополнил своими методами, а потом решил ещё пару[ десятков]? полей добавить. И всё. Значит мне нужно унаследовать от того, что мне gii нагенерит собственные классы моделей и править руками только их. Верно я мыслю?

Я в yii новичок (и вообще в популярных фреймворках), гляжу на gii и думаю. Допустим сгенерил он мне нужные классы. Я их дополнил своими методами, а потом решил ещё пару[ десятков]? полей добавить. И всё. Значит мне нужно унаследовать от того, что мне gii нагенерит собственные классы моделей и править руками только их. Верно я мыслю?

зачем наследовать, просто правишь, то что тебе gii сделал

можно и свой шаблон для gii забабахать, если требуется

зачем наследовать, просто правишь, то что тебе gii сделал

Но тогда gii не сможет сделать мне изменений, не перезатерев мои правки. Или сможет?

не может

Но тогда gii не сможет сделать мне изменений, не перезатерев мои правки. Или сможет?

так зачем изменения им делать, это же просто копипаст основы для crud

А где изменения делать?

Например, заменить input на словарь

руками делать нужно

Придется и в бд и в модели

Руками сделал, дальше понял, что поля не хватает, заменил в БД

Файлы затираются после перегенерации, ТС прав

так отнаследуйся от модели

и меняй модель хоть по 100 раз на дню

так зачем изменения им делать, это же просто копипаст основы для crud

Ну вот я сейчас сделал базу на две таблицы по три поля. И хочу уже это обкатать. Потом я захочу ещё 100500 полей в куче таблиц. Не хотелось бы это всё вручную писать (зачем мне gii тогда вообще). Если же он мне перепишет родительский класс, то всё что я дописал в дочернем сохранится, где надо я смогу переопределить метод (при этом если надо обращаться к родительскому через parent). Плюс некоторое уменьшение зависимости. Из минусов вижу разве что оверхед на "лишние" классы и наследование. Однако я могу не знать о какой-то причине почему так делать нельзя.

Ну вот я сейчас сделал базу на две таблицы по три поля. И хочу уже это обкатать. Потом я захочу ещё 100500 полей в куче таблиц. Не хотелось бы это всё вручную писать (зачем мне gii тогда вообще). Если же он мне перепишет родительский класс, то всё что я дописал в дочернем сохранится, где надо я смогу переопределить метод (при этом если надо обращаться к родительскому через parent). Плюс некоторое уменьшение зависимости. Из минусов вижу разве что оверхед на "лишние" классы и наследование. Однако я могу не знать о какой-то причине почему так делать нельзя.

ищи расширения или пиши такой функционал сам ?

так отнаследуйся от модели

Кроме модели нужно ещё править шаблон. Да и с наследованием код проще явно не становится.

если не менять поля то не нужно править шаблон

2 таблицы связаны М:1, gii генерирует на поле-связку input обычный, а нужен select. Как не править шаблон?

Есть у меня горький опыт проекта, где почти каждый объект был eav-сущностью. Студийный говнофреймворк сильно заточен под клепание сайтов, структура которых заранее не слишком то известна и под частые её изменения. Пока проекты были не слишком большими всё было прекрасно. Но потом стали появляться весьма тяжелые и дорогие проекты. И вот мой последний проект оказался этой фигне настолько не по силам, что лучше бы я его с нуля писал. Тогда то я очень горько пожалел, что не отделил код моделей от фреймворка. Оно там так переплелось, что изменить способ хранения и обработки какой-либо сущности без переписывания половины всего кода оказалось невозможно. Производительность на дне, впилить новую фичу и не добавить паре сотен миллисекунд целая история. Это был провал. В итоге ценой адских костылей с патчингом и переписыванием минимум 1/3 всего "системного" кода и бессоными ночами кое-как привёл всё это в условно пригодное состояние (к слову: некоторые фичи оказалось невозможно сделать быстрыми без автоматической кодогенерации и автоперекраивания структуры бд). Но на носу себе зарубил: логику хранения от бизнес логики нужно отделять. То же и для любого другого широко используемого инструмента. В любой момент может оказаться, что отныне он не годен и будет прекрасно, если заменить его частично или целиком можно будет более-менее безболезненно.

Пока я тут телегу писал на том самом проекте база сломалась %)

)))

Есть у меня горький опыт проекта, где почти каждый объект был eav-сущностью. Студийный говнофреймворк сильно заточен под клепание сайтов, структура которых заранее не слишком то известна и под частые её изменения. Пока проекты были не слишком большими всё было прекрасно. Но потом стали появляться весьма тяжелые и дорогие проекты. И вот мой последний проект оказался этой фигне настолько не по силам, что лучше бы я его с нуля писал. Тогда то я очень горько пожалел, что не отделил код моделей от фреймворка. Оно там так переплелось, что изменить способ хранения и обработки какой-либо сущности без переписывания половины всего кода оказалось невозможно. Производительность на дне, впилить новую фичу и не добавить паре сотен миллисекунд целая история. Это был провал. В итоге ценой адских костылей с патчингом и переписыванием минимум 1/3 всего "системного" кода и бессоными ночами кое-как привёл всё это в условно пригодное состояние (к слову: некоторые фичи оказалось невозможно сделать быстрыми без автоматической кодогенерации и автоперекраивания структуры бд). Но на носу себе зарубил: логику хранения от бизнес логики нужно отделять. То же и для любого другого широко используемого инструмента. В любой момент может оказаться, что отныне он не годен и будет прекрасно, если заменить его частично или целиком можно будет более-менее безболезненно.

?

?

реляции?

?

он рассказывал про EAV-модель

реляции?

Блин, случайно вставилось - сорь. Я про то что ты все правильно написал, что необходимо отделять логику хранения от фреймворка, если угодно даже вводить доп слой абстракции. Мы вот тоже на этапе реализации огромного проекта и твои "мысли в слух" подталкивают в нужном нправлении

он рассказывал про EAV-модель

и про то, что когда от неё пришлось отказаться это оказалось проблемно

и про то, что когда от неё пришлось отказаться это оказалось проблемно

само собой

Ппц. Мускуль стал во-первых писать кучу временных таблиц, во-вторых они у него на диск не помещаются (ну или ещё почему-то записать не может).

Интересно, есть ли аналог слова "говнокод" для администрирования? А то чтобы сервак поднять "шедевр" сотворил и не знаю какую табличку повесить.

Гавноконфиг)

Кто подскажет где можно посмореть на код более-менее крупного проекта на yii2. На гитхабе удалось найти только примеры блогов.

Кстати, да. Тоже интересует эта тема, а также т.н. best practices

Кто подскажет где можно посмореть на код более-менее крупного проекта на yii2. На гитхабе удалось найти только примеры блогов.

я пхпгикс скидывал

https://github.com/giovdk21/deployii https://github.com/komarserjio/notejam https://github.com/sadiqdon/cycommerce https://github.com/opus-online/yii2-app-ecom

> notejam a year ago > cycommerce 3 years ago >yii2-app-ecom > 2 years ago эх

Юпи еще

dotplant 2

Кто подскажет где можно посмореть на код более-менее крупного проекта на yii2. На гитхабе удалось найти только примеры блогов.

а смысл?

подсмотришь там какой нибудь трешак )

подсмотришь там какой нибудь трешак )

хорошо бы поглядеть что-нибудь, где весь трешак уже поправили) лучше конечно ещё и историю "как мы пилили проект, залезли в такое-то и такое-то дерьмо, вылезли из него тако-то и так-то и пришли к таким-то и таким-то выводам"

В yii можно стандартными средствами обрабатывать результат запроса в базу потоково (fetch а не fetchAll)?

Я так понимаю "полное руководство" ни разу не полное.

В yii можно стандартными средствами обрабатывать результат запроса в базу потоково (fetch а не fetchAll)?

foreach ($query->each() as $row)

А вот аналога fetchColumn не вижу.

А что ты хочешь? Не очень понял

В цикле получать по элементу колонки за раз, а не сразу целым массивом.

Прямо сейчас мне это не нужно, но хотелось бы знать.

Можно наверно просто выбрать одну колонку и each юзать, но тогда мы будем получать каждый раз массив на один элемент, а не сам этот элемент. Ничего страшного, но если можно без этого, то лучше без этого.

И ещё интересует насколько популярен в YII (и есть ли с этим какие-то проблемы) подход, когда большие списки обрабатываются, рендерятся и отдаются браузеру потоково, условно говоря в цикле: прочитали строку из базы, отрендерили кусок html/json/xml, отдали клиенту. Модель бы возвращала итератор. Хотел на тостере этот вопрос написать, да не знаю как сформулировать заголовок.