Комментарии 31
НЛО прилетело и опубликовало эту надпись здесь
сразу заметна неоднородность наименований классов (часть с неймспейсами, часть без)
можно пример подобных классов?
НЛО прилетело и опубликовало эту надпись здесь
Думаю, OnYourLips имел ввиду папку database, где лежат seeds и migrations. Но я бы не стал так категорично сетовать на неоднородность. Если говорить об однородности приложения, то тут все в порядке, а вышеупомянутые классы ничто иное как хелперы и на функциональность приложения никак не влияют и в общем-то не должны знать о приложении в принципе.
В Laravel 4 действительно была мешанина автозагрузки, но теперь все довольно лаконично:
По поводу вашей задачи для эликсира:
Добавить к этому примеру sass не составит труда
UPD: извините, ушел в магазин, когда начал писать ответ. Продолжил, когда вернулся, а вы уже ответили
В Laravel 4 действительно была мешанина автозагрузки, но теперь все довольно лаконично:
"autoload": {
"classmap": [
"database"
],
"psr-4": {
"App\\": "app/"
}
},
По поводу вашей задачи для эликсира:
elixir(function(mix) {
// сохраняем в css ресурсы
mix.less('app.less', 'resources/css');
});
elixir(function (mix) {
mix.styles([
// скомпилированный app.less и чистый page.css
"app.css",
"page.css"
], 'public/css/everything.css');
});
// объединенный файл с less и обычными стилями будет лежать тут public/css/everything.css
Добавить к этому примеру sass не составит труда
UPD: извините, ушел в магазин, когда начал писать ответ. Продолжил, когда вернулся, а вы уже ответили
Поковырялся в сорцах страниц, выдрал прямые ссылки на Laracasts.
1. Meet Composer
2. Virtual Machines and Homestead
3. A Gentle Introduction to Routing, Controllers, and Views
4. Passing Data to Views
5. Blade 101
6. Environments and Configuration
7. Migrations
8. Eloquent 101
9. Basic Model/Controller/View Workflow
10. Forms
11. Dates, Mutators, and Scopes
12. Form Requests and Controller Validation
13. View Partials and Form Reuse
14. Eloquent Relationships
15. Easy Auth
16. Ogres Are Like Middleware
17. Midterm Review
18. Route Model Binding
19. Manage Your Assets
20. Flash Messaging
21. Many to Many Relations (With Tags)
1. Meet Composer
2. Virtual Machines and Homestead
3. A Gentle Introduction to Routing, Controllers, and Views
4. Passing Data to Views
5. Blade 101
6. Environments and Configuration
7. Migrations
8. Eloquent 101
9. Basic Model/Controller/View Workflow
10. Forms
11. Dates, Mutators, and Scopes
12. Form Requests and Controller Validation
13. View Partials and Form Reuse
14. Eloquent Relationships
15. Easy Auth
16. Ogres Are Like Middleware
17. Midterm Review
18. Route Model Binding
19. Manage Your Assets
20. Flash Messaging
21. Many to Many Relations (With Tags)
Пробежал глазами заголовок, и прочел «Доигрались, релиз Laravel 5».
Ого, думаю, это ж чем так опасен 5й Laravel?
Надо больше спать.
Ого, думаю, это ж чем так опасен 5й Laravel?
Надо больше спать.
Господа, подскажите годную инструкцию по установке homestead для laravel 5 под windows 7.
Уже готов перевод документации: laravel.su/docs/5.0
Спасибо за ссылку, не знал о вашем ресурсе, думал единственный русскоязычный это laravel.ru
Кто-нибудь в курсе как в новую версию вписывается разработка собственных пакетов? Раньше можно было мучать workbench. Я верно понял что его «выпилили» и предлагают новые пакеты устанавливать через composer?
Taylor хотел уменьшить связь фреймворка с разрабатываемыми пакетами, поэтому да, прежний workbench «выпилен», а пакеты теперь разрабатываются по структуре, которую придумаете сами, но устанавливаются как и раньше, composer-ом
С одной стороны, конечно, здорово. С другой — доставляет определённое неудобство.
К примеру сейчас я веду работу над двумя пакетами. Одни использует в качестве зависимости второй. Получается что после того как я внёс изменения в пакет, то мне нужно закоммитить эти изменения и выполнить composer update в другом пакете.
Можно, конечно, использовать симлинки, но это как-то… неправильно, что ли.
К примеру сейчас я веду работу над двумя пакетами. Одни использует в качестве зависимости второй. Получается что после того как я внёс изменения в пакет, то мне нужно закоммитить эти изменения и выполнить composer update в другом пакете.
Можно, конечно, использовать симлинки, но это как-то… неправильно, что ли.
Для разработки лучше использовать не packagist пакеты а локальные репозитории. Как то так надо: coderwall.com/p/znlc-g/develop-symfony2-bundles-without-github-packagist
У меня так и сделано, вроде.
И получается, что бы в проекте inikulin/nourriture получить изменения, которые были сделаны в inikulin/gluten мне нужно сначала закоммитить и только после этого они подтягиваются композером.
По ссылке что вы дали автор пишет что можно сделать симлинк на репозиторий. Но этот метод, я так понимаю, в Windows не работает.
{
"name": "inikulin/nourriture",
"require": {
"inikulin/gluten": "*"
},
"autoload": {
"psr-4": {
"Nourriture\\": "src/"
}
},
"repositories": [
{
"type": "vcs",
"url": "/Users/inikulin/gluten"
}
],
"minimum-stability": "dev"
}
И получается, что бы в проекте inikulin/nourriture получить изменения, которые были сделаны в inikulin/gluten мне нужно сначала закоммитить и только после этого они подтягиваются композером.
По ссылке что вы дали автор пишет что можно сделать симлинк на репозиторий. Но этот метод, я так понимаю, в Windows не работает.
Что вам мешает использовать симлинки в виндовс? Если только вы не на Windows XP или ниже.
Символическая ссылка (symbolic links) — доступна с Windows Vista. en.wikipedia.org/wiki/NTFS_symbolic_link
Но все равно эта все похоже на костыль. Для локальной разработки библиотек надо строить дев окружение, а все остальные участники должны забирать обновления из удаленных репозиториев. Если вам хочется подключать локальные библиотеки, то надо или допилить автолоадер или иметь разные composer.json для вашего локального окружения и для продакшена. Тогда в локальном composer.json можно указать локальные пути библиотек для автолоадера. А в ide их добавить как внешние библиотеки.
Символическая ссылка (symbolic links) — доступна с Windows Vista. en.wikipedia.org/wiki/NTFS_symbolic_link
Но все равно эта все похоже на костыль. Для локальной разработки библиотек надо строить дев окружение, а все остальные участники должны забирать обновления из удаленных репозиториев. Если вам хочется подключать локальные библиотеки, то надо или допилить автолоадер или иметь разные composer.json для вашего локального окружения и для продакшена. Тогда в локальном composer.json можно указать локальные пути библиотек для автолоадера. А в ide их добавить как внешние библиотеки.
Мешает как раз то что это костыль.
Кстати, раз вы упомянули разные composer.json в зависимости от окржужения. Есть какой-нибудь рецепт как это организовать? Исключать сам composer.json и вместо него коммитить некий composer.json.dist?
Кстати, раз вы упомянули разные composer.json в зависимости от окржужения. Есть какой-нибудь рецепт как это организовать? Исключать сам composer.json и вместо него коммитить некий composer.json.dist?
Я бы попробовал сделать трюк с автолоадером, и перезаписывать пути к папкам в локальной версии приложения. Вот как тут stackoverflow.com/questions/28106850/how-to-use-composer-to-load-php-classes-from-local-repository и просто подключать локальный файл с доп правилами если есть. Или пойти глубже и написать плагин (или хук) для композера который будет зависеть от какого нибудь local_composer.json =)
Но этот метод, я так понимаю, в Windows не работает.
Если вы используете например Vagrant, то это не проблема.
Буквально на днях на packagist появился пакет, вроде как решающий вашу проблему. Подробно не смотрел, больше сказать не могу
Напрягает немного, что заинтерфейсили почти всё, а Eloquent, QueryBuilder технично обошли стороной.
Безопасно ли обновляться с 4-ой версии?
В каком плане безопасно? Например, Jeffrey Way перевел Laracasts на 5ую версию за вечер и был весьма рад этому событию :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дождались, релиз Laravel 5