Comments 68
Весь Laravel похож на один огромный велосипед. Кучу вещей которые сделаны не логично, много лишнего кода, нет какого-то единого стиля.
Хотелось бы узнать, что в
Laravel выглядит не логично?Например шаблонизатор, я даже не говорю о том, что есть множество достойных шаблонизаторов, которые можно было бы использовать: синтаксис вывода переменных и условных операторов отличается кардинально, каких-то «фишек» шаблонизатор особо не дает, по сути это чистый PHP, так зачем же мне изучать совершенно новый синтаксис, чтобы вывести пару переменных в шаблоне?
Давайте рассмотрим подробно каждый из ужасов:
1) Скаффолдинг:
Если уж делать скаффолдинг то давайте уже диалогом, как например у Yii. Вы нарисовали схему с внешними ключами, но ваш скаффолдинг самых то ключей не создал. Для этого вы потом еще одну команду пишете для генерации ключей. Так для чего мне это? Я БЫСТРЕЕ напишу для каждой таблички 1 строку SQL и создам сразу и табличку и связь.
2) Валидация.
Компактно конечно, но никак не понятно как например добавить свою проверку. Нельзя вот так делать все на стрингах, парсить вперед назад. Где ООП?
3) Blade. А зачем он написан вообще? Полностью то же самое что Твиг. Если и так использовать Симфони компоненты используйте сразу и твиг а не велосипед.
4) Статик методы везде!!! И да я уже слышал что это только фасад и на самом деле там все ООП в глубине, но ведь программист то работает как раз со статическим интерфейсом. А потом гляди и сам начнет статику повсюду писать (ведь если фреймворк так делает, значит так надо).
5) Где динамический роутинг? Мне это все что руками прописывать надо?
6) Выключайте дебаг на продакшене!!! habr.eu1.frbit.net/offer_4.%D0%BF%D0%BF%D0%BF
1) Скаффолдинг:
php artisan generate:scaffold offer --fields="title:string, description:text, city_id:integer:unsigned, company_id:integer:unsigned, off:integer:unsigned, image:string, expires:date"Если уж делать скаффолдинг то давайте уже диалогом, как например у Yii. Вы нарисовали схему с внешними ключами, но ваш скаффолдинг самых то ключей не создал. Для этого вы потом еще одну команду пишете для генерации ключей. Так для чего мне это? Я БЫСТРЕЕ напишу для каждой таблички 1 строку SQL и создам сразу и табличку и связь.
2) Валидация.
'required|email|unique:users,email'Компактно конечно, но никак не понятно как например добавить свою проверку. Нельзя вот так делать все на стрингах, парсить вперед назад. Где ООП?
3) Blade. А зачем он написан вообще? Полностью то же самое что Твиг. Если и так использовать Симфони компоненты используйте сразу и твиг а не велосипед.
4) Статик методы везде!!! И да я уже слышал что это только фасад и на самом деле там все ООП в глубине, но ведь программист то работает как раз со статическим интерфейсом. А потом гляди и сам начнет статику повсюду писать (ведь если фреймворк так делает, значит так надо).
5) Где динамический роутинг? Мне это все что руками прописывать надо?
6) Выключайте дебаг на продакшене!!! habr.eu1.frbit.net/offer_4.%D0%BF%D0%BF%D0%BF
1) Кроме самого файла миграции будут созданы так же другие необходимые файлы (вьюшки, модель, контроллер)
2) Добавить свою проверку / свои сообщения об ошибках можно! Validator::make($input, $rules, $message) — все кастомно. Можно и свои правила придумывать: custom-validation-rules.
3) Это уже прихоть Taylor Otwell.
4) Не считаю это неудобным. Или минусом. Вполне удобно пользоваться.
5) Проясните что конкретно имеется в виду.
6) Сделал. Спасибо за поправку. Три дня модерацию статья проходила, совсем забыл убрать это.
2) Добавить свою проверку / свои сообщения об ошибках можно! Validator::make($input, $rules, $message) — все кастомно. Можно и свои правила придумывать: custom-validation-rules.
3) Это уже прихоть Taylor Otwell.
4) Не считаю это неудобным. Или минусом. Вполне удобно пользоваться.
5) Проясните что конкретно имеется в виду.
6) Сделал. Спасибо за поправку. Три дня модерацию статья проходила, совсем забыл убрать это.
Лично мне статика не нравится ощущением отсутствия структуры. То есть я могу что угодно и отукуда угодно сделать. Вы можете сказать что это плюс, так как вы сами управляете тем как устроено ваше приложение, но на самом деле это дает поводов добавлять костыли откуда хочешь, когда хочешь и как хочешь.
Просили передать (RO на хабре): «в ларевеле не статика, а скорее статическая делегация к сервисам»
Ага, а в yii App::app() — доступ до контейнера)
Так или иначе я могу в любой момент сделать что хочу и откуда хочу. Так быть не должно
Так или иначе я могу в любой момент сделать что хочу и откуда хочу. Так быть не должно
То что плохо — спорный вопрос, всё же предоставлять доступ к публичным частям системы без геммороя — лучше, имхо, чем устраивать карусель с делегацией, хотя с другой стороны — публичность в кривых руках… То что доступ через синглтон App::** лучше — соглашусь, мне это больше нравится (уже корячился с ларавелью в разделении на несколько проектов, которые используют одно ядро — это, мммм, немного трудновато, скажем так).
Вы меня не поняли)
Я не считаю, что App::* лучше, на мой взгляд это наоборот хуже. Я не знаю в каких случаях это нужно. Уже есть общепризнанный паттерн внедрения зависимостей, зачем контроллеру знать о том что он часть приложения — не понятно. Он должен лишь знать что ему нужно это и то (желательно не конкретно, а такого-то интерфейса) и получать. Тогда все прекрасно мокается, заменяется и тд и тп.
Я не считаю, что App::* лучше, на мой взгляд это наоборот хуже. Я не знаю в каких случаях это нужно. Уже есть общепризнанный паттерн внедрения зависимостей, зачем контроллеру знать о том что он часть приложения — не понятно. Он должен лишь знать что ему нужно это и то (желательно не конкретно, а такого-то интерфейса) и получать. Тогда все прекрасно мокается, заменяется и тд и тп.
Прочитайте laravel.com/docs/ioc глава Binding An Interface To An Implementation
1) Это все мусор. Зачем мне эти вюшки и контроллер? Итак все будет переделываться так как мне нужно. Я не видел ни одного сайта который бы использовал контроллеры которые сгенерил скаффолдинг. Генерация моделей это еще куда не шло, но контроллер это мусор.
2) Можно, но непрозрачно. Если я смотрю на какой-то стринг, мне нифига не ясно что он делает и кто его обрабатывает.
4) Есть много причин почему статика зло. Можете погуглить =)
5) Ну например в кохане есть дефолтный роут /controller/action, тоесть если я зайду на /comments/add, то это будет Comments контроллер и action_add() метод.
P.S. Статья довольно хорошо написанная. Критика в сторону фреймворка а не автора
2) Можно, но непрозрачно. Если я смотрю на какой-то стринг, мне нифига не ясно что он делает и кто его обрабатывает.
4) Есть много причин почему статика зло. Можете погуглить =)
5) Ну например в кохане есть дефолтный роут /controller/action, тоесть если я зайду на /comments/add, то это будет Comments контроллер и action_add() метод.
P.S. Статья довольно хорошо написанная. Критика в сторону фреймворка а не автора
1) Здесь скаффолдинг применен для того, чтобы быстрого прототипирования.
2) Можно в модели правила валидации для прозрачности. Полный набор доступных с коробки правил есть тут: Available Validation Rules. Стринга легко читается и понятна
4) Почитаю.
5) Такое есть и
Спасибо за комментарий.
2) Можно в модели правила валидации для прозрачности. Полный набор доступных с коробки правил есть тут: Available Validation Rules. Стринга легко читается и понятна
'field' => 'rule1|rule2|rule3:option1,option2,etc...': каждое правило разделяется |, опции добавляются после двоеточия и разделяются запятой.4) Почитаю.
5) Такое есть и
Laravel, это называется RESTful Controllers.Спасибо за комментарий.
1) Не нужно, не генерируйте, в конце концов это только сторонние расширение.
2) А как бы вы сделали валидацию? Вот где не понятно, так это в Yii, там объединение по правилам идет, а не по полям.
3) Вы наверное плохо поняли, там нет статики.
4) Дефолтных роутов нет, но для работы с каждым контролером нужно написать всего 1 строчку.
2) А как бы вы сделали валидацию? Вот где не понятно, так это в Yii, там объединение по правилам идет, а не по полям.
3) Вы наверное плохо поняли, там нет статики.
4) Дефолтных роутов нет, но для работы с каждым контролером нужно написать всего 1 строчку.
3) Есть там статика. И она там везде. Глядя на всю эту простыню из вызовов Some::method() даже грустно стало. С таким же успехом могли наопределять в процедур-стайле кучу функций some_method() а потом попросить передать «это не процедур-стайл, а скорее процедурная делегация к сервисам»
2. Пишете свой класс «CustomValidator», наследуетесь от Illuminate\Validation\Validator.
Например, требуется правило для подсчета кол-ва элементов в массиве с min/max. Пишете метод в классе:
class CustomValidator extends Validator
{
public function validateArrayConut($attribute, array $array, $parameters) {
if(count($array) < $parameters[0] OR count($array) > $parameters[1]) {
return false;
}
}
}
потом в правилах
'required|array_count:3,10', где 3 — минимальное кол-во элементов, а 10 — максимальное. Кстати, правила так же могут быть массивом:
$rules = array('required', 'array_count:3,10');
3. Я вообще против шаблонизаторов
4. So what?
5. Очень удобная штука. Избавляет от надоедливых префиксов action и вы задаете только те роуты, которые должны работать. Никто не попадет «куда не надо».
Например, требуется правило для подсчета кол-ва элементов в массиве с min/max. Пишете метод в классе:
class CustomValidator extends Validator
{
public function validateArrayConut($attribute, array $array, $parameters) {
if(count($array) < $parameters[0] OR count($array) > $parameters[1]) {
return false;
}
}
}
потом в правилах
'required|array_count:3,10', где 3 — минимальное кол-во элементов, а 10 — максимальное. Кстати, правила так же могут быть массивом:
$rules = array('required', 'array_count:3,10');
3. Я вообще против шаблонизаторов
4. So what?
5. Очень удобная штука. Избавляет от надоедливых префиксов action и вы задаете только те роуты, которые должны работать. Никто не попадет «куда не надо».
Почему-то мне написать префикс action_ проще чем руками весь рут прописать
Тут дело эстетики. Мне лично не нравится префикс action. Я пишу что-то, хочу прописать какой-то роут (в любом стиле), я не хочу чтобы фреймворк сам роутил до моего контроллера. + artisan routes выведет полный список роутов, где я смотрю посмотреть какие фильтры применены и как собственно роутинг проводится.
Попробуйте написать какой-нибудь проект на Laravel, но только в Laravel-style и тогда поймете смак этого фреймворка. Еще рекомендую к прочтению leanpub.com/laravel от Taylor Otwell, который пишет как стоит писать на Laravel.
Попробуйте написать какой-нибудь проект на Laravel, но только в Laravel-style и тогда поймете смак этого фреймворка. Еще рекомендую к прочтению leanpub.com/laravel от Taylor Otwell, который пишет как стоит писать на Laravel.
Да не вопрос. Пишем Route::controller('users', 'UserController');
И будет вам счастье. Даже больше.
/user/ — getIndex()
/user/profile/ — getProfile()
и т.д.
Как бонус можно разделить обработку get, post отдельными методами getIndex() postIndex()
или использовать общий anyIndex() — полный аналог вашего любимого action_*
И будет вам счастье. Даже больше.
/user/ — getIndex()
/user/profile/ — getProfile()
и т.д.
Как бонус можно разделить обработку get, post отдельными методами getIndex() postIndex()
или использовать общий anyIndex() — полный аналог вашего любимого action_*
[offtop]
В русском языке слово фамильярный имеет «немного» другое значение :)
[/offtop]
Если вы фамильярны с другими PHP фреймворками
В русском языке слово фамильярный имеет «немного» другое значение :)
[/offtop]
Кстати недавно узнал о rad-bundle. Очень интересная штука, не такая мощная, как ларавел, но добавляет «синтаксического сахара» symfony. И самое главное без обилия статики. Любителям laravel советовал бы взглянуть)
Статика в ларавеле для синтаксического сахара, да и со времён php 5.4 и доступности static она стала законной и не влечёт за собой проблем с расширением и переобределением, тем более там юзается паттерн facade.
Лучшее доказательство — прекрасная тестабилити фреймворка и проектов созданных на нём.
Ложка дёштя — автокомплит, но это в основном из-за популярности сублайма среди разработчиков, которые ленятся прописать правильный phpdoc
Лучшее доказательство — прекрасная тестабилити фреймворка и проектов созданных на нём.
Ложка дёштя — автокомплит, но это в основном из-за популярности сублайма среди разработчиков, которые ленятся прописать правильный phpdoc
Автокомплит лечится =)
Спасибо за проделанную работу.
думал, что это огромное скопище перевода medium (типа medium.com/on-coding/3bed5d0e645e, medium.com/on-coding/c643022433ad и medium.com/on-coding/e8d93c9ce0e2) и codeforest (4 части www.codeforest.net/laravel4-simple-website-with-backend-1), но вроде как ошибся.
на недельку бы раньше этот пост и я бы еще больше благодарен, спасибо)
еще для меня полезным оказался данный сборник cheats.jesse-obrien.ca/
на недельку бы раньше этот пост и я бы еще больше благодарен, спасибо)
еще для меня полезным оказался данный сборник cheats.jesse-obrien.ca/
Спасибо за ссылки. Последнюю, пожалуй, добавлю в статью.
Стоит добавить еще laracasts.com/
Недавно открытый одним из разработчиков Laravel. Всего за 9$ в месяц постоянно добавляю новые видеоуроки по Laravel. + если вы зарегистрируетесь в течении 2х месяцев бесплатно прилагается книга «Laravel: Testing Decoded», в которой описывается как нужно тестировать приложения, Mockery, TDD и как все это круто тестируется в Laravel при правильной архитектуре
Недавно открытый одним из разработчиков Laravel. Всего за 9$ в месяц постоянно добавляю новые видеоуроки по Laravel. + если вы зарегистрируетесь в течении 2х месяцев бесплатно прилагается книга «Laravel: Testing Decoded», в которой описывается как нужно тестировать приложения, Mockery, TDD и как все это круто тестируется в Laravel при правильной архитектуре
Зачем нужен при установке Laravel build-essential, если L4 ставится из composer?
Причем здесь python-software-properties?
А что, в Ubuntu php нет?
Тогда зачем ppa:ondrej/php5?
Если уж sudo apt-get update, то следует и upgrade сделать.
Все нужно вносить в apache2.conf?
# Хак для phpmyadmin
echo «Include /etc/phpmyadmin/apache.conf» | sudo tee -a /etc/apache2/apache2.conf
# Перезапустим apache
sudo /etc/init.d/apache2 restart
# Включение mod_rewrite
sudo a2enmod rewrite
Директиву Include в apache уже отменили?
Включать модуль в apache можно только после рестарта apache?
И зачем вам флаг yes при установке? А если нет?
P.S.
Я не критикую Laravel, в 3-й версии это был очень интересный фреймворк.
Мой ник на российском сайте Laravel — oleg578.
Причем здесь python-software-properties?
А что, в Ubuntu php нет?
Тогда зачем ppa:ondrej/php5?
Если уж sudo apt-get update, то следует и upgrade сделать.
Все нужно вносить в apache2.conf?
# Хак для phpmyadmin
echo «Include /etc/phpmyadmin/apache.conf» | sudo tee -a /etc/apache2/apache2.conf
# Перезапустим apache
sudo /etc/init.d/apache2 restart
# Включение mod_rewrite
sudo a2enmod rewrite
Директиву Include в apache уже отменили?
Включать модуль в apache можно только после рестарта apache?
И зачем вам флаг yes при установке? А если нет?
P.S.
Я не критикую Laravel, в 3-й версии это был очень интересный фреймворк.
Мой ник на российском сайте Laravel — oleg578.
Инструкцию по настройке
Перезапуск apache для принятия изменения конфига. И правильно вы заметили, что перезапуск нужно сделать после включения mod_rewrite.
Флаг — для ускорения процесса установки.
LAMP сервера я брал отсюда. (к build-essential и python-software-properties), мало ли кому захочется не только в Laravel покопаться, но и другие фреймворки/еще что-то попробовать.Перезапуск apache для принятия изменения конфига. И правильно вы заметили, что перезапуск нужно сделать после включения mod_rewrite.
Флаг — для ускорения процесса установки.
Эту «инструкцию» — в топку!
Хабр — достаточно весомый ресурс, чтобы использовать на нем сомнительные материалы.
Эта «инструкция» как раз из таких.
Хабр — достаточно весомый ресурс, чтобы использовать на нем сомнительные материалы.
Эта «инструкция» как раз из таких.
Считаете данную инструкцию недостойной?
Предложите свою. Я могу внести ее в статью.
Предложите свою. Я могу внести ее в статью.
Я уже давно не пользуюсь Ubuntu. Равно как и apache.
На серверах использую debian + lighttpd, до недавнего времени nginx.
Тем не менее…
Для установки готовых пакетов, в том числе и в Ubuntu, нет смысла устанавливать build--essential.
Установка composer более, чем точно, описана на getcomposer.org.
Я ставлю composer в ~/.composer/bin/composer и включаю в PATH.
Больше с ним хлопот нет.
Наиболее удобное конфигурирование apache у debian.
Тут даже инструкции никакие не нужны. Достаточно посмотреть документацию и файловую структуру пакета.
Смысл моего замечания в том, что нужно тщательно проверять информацию перед тем, как ее подавать. Вы должны быть уверены в точности поданого материала. Вы же его представляете читателям.
В конце кноцов, если вам это не по-плечу, можете просто установить весь стек LAMP посредством tasksel. Пакет PHPMyAdmin также имеет возможность автоматической настройки apache для использования при установке пакета.
Т.е.:
sudo apt-get install tasksel
sudo tasksel
sudo apt-get install phpmyadmin
sudo invoke-rc.d apache2 restart
Должно быть достаточно для конфигурации по умолчанию
Меня этому в КПИ учили. Но немножко раньше.
На серверах использую debian + lighttpd, до недавнего времени nginx.
Тем не менее…
Для установки готовых пакетов, в том числе и в Ubuntu, нет смысла устанавливать build--essential.
Установка composer более, чем точно, описана на getcomposer.org.
Я ставлю composer в ~/.composer/bin/composer и включаю в PATH.
Больше с ним хлопот нет.
Наиболее удобное конфигурирование apache у debian.
Тут даже инструкции никакие не нужны. Достаточно посмотреть документацию и файловую структуру пакета.
Смысл моего замечания в том, что нужно тщательно проверять информацию перед тем, как ее подавать. Вы должны быть уверены в точности поданого материала. Вы же его представляете читателям.
В конце кноцов, если вам это не по-плечу, можете просто установить весь стек LAMP посредством tasksel. Пакет PHPMyAdmin также имеет возможность автоматической настройки apache для использования при установке пакета.
Т.е.:
sudo apt-get install tasksel
sudo tasksel
sudo apt-get install phpmyadmin
sudo invoke-rc.d apache2 restart
Должно быть достаточно для конфигурации по умолчанию
Меня этому в КПИ учили. Но немножко раньше.
справедливости ради стоит отметить, что топик-то вообще никак не про убунту, апач и не про то, как их устанавливать и конфигурировать.
топик про laravel и все вводные части про сервера и т.д. можно вынести за статью.
ума не приложу что вас так тревожит (в интернете кто-то неправ, полагаю?), ибо я, например, эту часть вообще пропустил как лишнюю, ибо основная мысль здесь — laravel, php и примеры их использования. yet another quick start, если хотите.
з.ы. собственно, поэтому и минуснул ваш предыдущий комментарий, если уж здесь принято аргументировать минусы.
топик про laravel и все вводные части про сервера и т.д. можно вынести за статью.
ума не приложу что вас так тревожит (в интернете кто-то неправ, полагаю?), ибо я, например, эту часть вообще пропустил как лишнюю, ибо основная мысль здесь — laravel, php и примеры их использования. yet another quick start, если хотите.
з.ы. собственно, поэтому и минуснул ваш предыдущий комментарий, если уж здесь принято аргументировать минусы.
В вашей инструкции, если честно, как для новичка в настройке сервера все выглядит немного сложнее, чем в моей статье.
1) Что делать после команды
Здесь, как по мне, должна прилагаться (комментариями или картинками) последовательность действий после запуска этой команды. Что в принципе сложнее, чем в «инструкции», которая есть.
2) После установки phpmyadmin и рестарта
3) Свой вариант я протестировал, и он работает.
Ваш добавлю как альтернативный — только допишите, пожалуйста подробный порядок действий и протестируйте его работоспособность.
1) Что делать после команды
sudo tasksel? Здесь, как по мне, должна прилагаться (комментариями или картинками) последовательность действий после запуска этой команды. Что в принципе сложнее, чем в «инструкции», которая есть.
2) После установки phpmyadmin и рестарта
apache будет открываться сам phpmyadmin? На моей машине (Ubuntu 12.04), к примеру без записи в апаче конфиг (#Хака, который присутсвует в инструкции) и рестарта он не открывался.3) Свой вариант я протестировал, и он работает.
Ваш добавлю как альтернативный — только допишите, пожалуйста подробный порядок действий и протестируйте его работоспособность.
UFO just landed and posted this here
a2enmod — apache2 enable module.
Директива Include служит для включения дополнительных настроек в сервер apache. Для этого-же служит и директория conf.d в /etc/apache2. Т.е. для включения phpmyadmin достаточно сделать ссылку в /etc/apache2/conf.d на конфиг phpmyadmin.
Суть разные понятия.
L4 требует php 5.3.7 > — в Ubuntu (LTS) 5.3.10 + mcrypt.
Т.е использование в Laravel PHP 5.5 просто бесполезно.
Теперь касательно apache, Ubuntu и Laravel.
Вот вы ставите полный стек LAMP, Composer, настраивайте сервер apache.
Создаете приложение…
И, торжественно:
Перейдем в созданный проект и убедимся, что все работает, запустив команду php artisan serve
cd habr
php artisan serve
Вопрос — какой сервер вы запускаете командой artisan serve?
Сразу задам вам следующий вопрос, предполагая правильный ответ на предыдущий —
ЗАЧЕМ вам apache для девелопинга Laravel на localhost, если вы его не используете?
True Way?
И я абсолютно согласен, при чем здесь Ubuntu. Ubuntu здесь совершенно ни при чем.
Для справки;
vendor/laravel/framework/src/Illuminate/Foundation/Console/ServeCommand.php
41 passthru(«php -S {$host}:{$port} -t \»{$public}\" server.php");
Директива Include служит для включения дополнительных настроек в сервер apache. Для этого-же служит и директория conf.d в /etc/apache2. Т.е. для включения phpmyadmin достаточно сделать ссылку в /etc/apache2/conf.d на конфиг phpmyadmin.
Суть разные понятия.
L4 требует php 5.3.7 > — в Ubuntu (LTS) 5.3.10 + mcrypt.
Т.е использование в Laravel PHP 5.5 просто бесполезно.
Теперь касательно apache, Ubuntu и Laravel.
Вот вы ставите полный стек LAMP, Composer, настраивайте сервер apache.
Создаете приложение…
И, торжественно:
Перейдем в созданный проект и убедимся, что все работает, запустив команду php artisan serve
cd habr
php artisan serve
Вопрос — какой сервер вы запускаете командой artisan serve?
Сразу задам вам следующий вопрос, предполагая правильный ответ на предыдущий —
ЗАЧЕМ вам apache для девелопинга Laravel на localhost, если вы его не используете?
True Way?
И я абсолютно согласен, при чем здесь Ubuntu. Ubuntu здесь совершенно ни при чем.
Для справки;
vendor/laravel/framework/src/Illuminate/Foundation/Console/ServeCommand.php
41 passthru(«php -S {$host}:{$port} -t \»{$public}\" server.php");
> ЗАЧЕМ вам apache для девелопинга Laravel на localhost, если вы его не используете?
Ответ прост: для
Ответ прост: для
phpmyadmin.Ответ, конечно, тронул до души.
Справедливости ради следует заметить, что L4 требует php 5.3.7, но при этом использует встроенный сервер php, который появился только в 5.4 (специально документацию посмотрел, потому что уже работаю в php 5.5, а на серверах использую 5.4.). Может — это не так?
Справедливости ради следует заметить, что L4 требует php 5.3.7, но при этом использует встроенный сервер php, который появился только в 5.4 (специально документацию посмотрел, потому что уже работаю в php 5.5, а на серверах использую 5.4.). Может — это не так?
Вы меня заинтриговали, и я проверил специально.
Для phpmyadmin apache не нужен. Достаточно встроенного php сервера.
Пришлось сделать проброс с виртуалки, конечно, но занятно.
Для phpmyadmin apache не нужен. Достаточно встроенного php сервера.
Пришлось сделать проброс с виртуалки, конечно, но занятно.
Спасибо, буду знать )
Конечно, нужно установить Mysql, или MariaDB
Команда для запуска phpmyadmin:
php -S localhost:9000 -t /usr/share/phpmyadmin/
Порт можно указать по своему усмотрению.
В некоторых дистрибутивах конструкция localhost подразумевает роутинг IPv6.
Некоторые браузеры это не «понимают», поэтому localhost можно заменить на 127.0.0.1
Команда для запуска phpmyadmin:
php -S localhost:9000 -t /usr/share/phpmyadmin/
Порт можно указать по своему усмотрению.
В некоторых дистрибутивах конструкция localhost подразумевает роутинг IPv6.
Некоторые браузеры это не «понимают», поэтому localhost можно заменить на 127.0.0.1
UFO just landed and posted this here
Я работаю с php 5.4.4-14+deb7u4. Хотя на десктопе у меня Arch и, соответственно php 5.5. С трейтами сейчас не работаю, т.к. использую PhalconPHP.
Хотел по поводу трейтов заметку написать, руки не дошли. Если интересно, можете мой github посмотреть github.com/oleg578/DependencyInjectionPHP
Хотел по поводу трейтов заметку написать, руки не дошли. Если интересно, можете мой github посмотреть github.com/oleg578/DependencyInjectionPHP
Лично мне кажется, что здесь уж много велосипедов наново создавались…
Я не могу критиковать данный фраемворк, так как с ним не работал, но по посту было замечено:
1. Создания сущностей немного сложноватое. Если посмотреть в сторону Doctrine 2 (Symfony2/DoctrineBundle), то там все намного проще и лаконичней. Все связи определяются в одном классе, при этом будут созданы все необходимые ключи.
2. Миграции. А зачем они были вообще созданы? Чтобы во время разработки приложения создавать связи? habrahabr.ru/post/121265/
Если я не ошибаюсь, то «миграции» создаются в целях «без болезненного» перехода на новую архитектуру (Изменился тип поля в БД, либо добавлено новое)
3. Темизатор. Не один раз уже вижу в инете куча новыхвозможно и классных темизаторов. Но зачем наново создают велосипеды? Чтобы потом сказать: «ЭТО Я СДЕЛАЛ, но у меня времени не было, чтобы его сделать так как Twig, или Smarty»
4. Все на статике. Лично я не поклонник статики в таком объеме, по той причине, что нету возможности хорошо указать зависимости среди сервисов, сделать override того или инного сервиса, не наступая на грабли и не создавая своих костылей.
P.S. Круто, супер, новая система, новый фремворк, новые знания, достижения!!! Но задайте себя вопросом, бедет ли он уместен на ОЧЕНЬ больших проектах, где архитектурное решение — самое главное в разработке?
P.S.S. Автору большое спасибо за статью, познавательно!
Я не могу критиковать данный фраемворк, так как с ним не работал, но по посту было замечено:
1. Создания сущностей немного сложноватое. Если посмотреть в сторону Doctrine 2 (Symfony2/DoctrineBundle), то там все намного проще и лаконичней. Все связи определяются в одном классе, при этом будут созданы все необходимые ключи.
2. Миграции. А зачем они были вообще созданы? Чтобы во время разработки приложения создавать связи? habrahabr.ru/post/121265/
Если я не ошибаюсь, то «миграции» создаются в целях «без болезненного» перехода на новую архитектуру (Изменился тип поля в БД, либо добавлено новое)
3. Темизатор. Не один раз уже вижу в инете куча новых
4. Все на статике. Лично я не поклонник статики в таком объеме, по той причине, что нету возможности хорошо указать зависимости среди сервисов, сделать override того или инного сервиса, не наступая на грабли и не создавая своих костылей.
P.S. Круто, супер, новая система, новый фремворк, новые знания, достижения!!! Но задайте себя вопросом, бедет ли он уместен на ОЧЕНЬ больших проектах, где архитектурное решение — самое главное в разработке?
P.S.S. Автору большое спасибо за статью, познавательно!
1. Пример создания сущности:
Тут все связи заданы. Или я понял не так?
2. К примеру во время dev вся схема БД создается постепенно, а на production можно сразу прогнать все миграции вместо экспорта БД из дева.
3. Ничего не могу тут ответить )) Дела автора. Меня, в принципе, устраивает.
4. По этому поводу есть много мнений и даже статей. Кому что )
И вам спасибо за комментарий!
class Offer extends Eloquent {
protected $guarded = array();
public function city()
{
return $this->belongsTo('City');
}
public function company()
{
return $this->belongsTo('Company');
}
public function tags()
{
return $this->belongsToMany('Tag');
}
public function usersComments()
{
return $this->belongsToMany('User', 'comments')->withPivot('body', 'mark')->withTimestamps();
}
}
Тут все связи заданы. Или я понял не так?
2. К примеру во время dev вся схема БД создается постепенно, а на production можно сразу прогнать все миграции вместо экспорта БД из дева.
3. Ничего не могу тут ответить )) Дела автора. Меня, в принципе, устраивает.
4. По этому поводу есть много мнений и даже статей. Кому что )
И вам спасибо за комментарий!
1. Да, возможно этот момент и хорош, но давайте посмотрим на Doctrine: docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/association-mapping.html Как по мне, лучше, чем в методах писать вызовы доп. функций, тем более унаследовать. Это ведь просто сущность?
2. Здесь наверное нужно четко распределить, что же такое «схема БД» и «миграция»!
3. Ну главное, чтобы разработчику было уютно в своем коде! :)
4. Верно, кому как. Но этот подход намного тяжелее поддерживать, тестировать. Вот к примеру мы захотим протестить сервис, который вызывает другой сервис через статику…
2. Здесь наверное нужно четко распределить, что же такое «схема БД» и «миграция»!
3. Ну главное, чтобы разработчику было уютно в своем коде! :)
4. Верно, кому как. Но этот подход намного тяжелее поддерживать, тестировать. Вот к примеру мы захотим протестить сервис, который вызывает другой сервис через статику…
1. Интересный подход. А там есть Eager Loading / Lazy Eager Loading. Всю документацию из Doctrine не прочел, но заметил, что там используется __construct() для 6.5 — 6.10.
2. Миграции это своеобразный
4. У них есть документация по Unit Testing. И достаточно литературы (пример) по этому поводу. Многое уже ранее в комментариях было сказано по поводу «статики».
2. Миграции это своеобразный
git для БД, с помощью которого мы создаем/изменяем/удаляем таблицы с полями/индексами/и т.д. 4. У них есть документация по Unit Testing. И достаточно литературы (пример) по этому поводу. Многое уже ранее в комментариях было сказано по поводу «статики».
1. docs.doctrine-project.org/en/latest/reference/working-with-objects.html#by-eager-loading
2. Это спорный вопрос, но в большинстве ответят: Зачем это делать, если это умеет делать ORM. Если фраемворк так устроен, то значит так нужно :)
4. Ну а Вы как считаете, что лучше тестировать? Статику или объекты созданные с конструктора?
2. Это спорный вопрос, но в большинстве ответят: Зачем это делать, если это умеет делать ORM. Если фраемворк так устроен, то значит так нужно :)
4. Ну а Вы как считаете, что лучше тестировать? Статику или объекты созданные с конструктора?
2. Ну, к примеру, взять мою статью. Заходим на github, клоним проект, изменяем конфиг БД на свой, далее 2 строчки в терминале:
И все таблицы созданы + если есть seeds — то и конфигурационные данные будут внесены.
4. Ответить на этот вопрос я вам пока что не могу, так как у меня еще слишком мало опыта.
php atrisan migrate:install
php artisan migrate --seedИ все таблицы созданы + если есть seeds — то и конфигурационные данные будут внесены.
4. Ответить на этот вопрос я вам пока что не могу, так как у меня еще слишком мало опыта.
Вконтактик, конечно, на нем не напишешь… что в Вашем понимании большой проект? Это посещаемость 1000/сутки? 200 000 сутки? 1 млн/сутки? Или, к примеру, 200-250 человек онлайн достаточно будет? (у меня проект небольшой, как я считаю, крутится на средненьком сервере на хетцнере, 200-250 менеджеров в онлайн, «менеджерят» свои данные, постоянно лопатят базу и добавляют всякую фиговину туда)… Laravel 4 — отлично себя уже показал.
Если кого заинтересовала тема
Laravel — могу написать еще пару статей по возможностям данного фреймворка.
В ларе версии выше 4.1.25 при авторизации, если делать все следуя вашей статье, появится ошибка
Связанно это с обновлением безопасности в версии 4.1.26 (http://laravel.com/docs/upgrade), где закрывали дыру с похищенными куками. Исправить очень легко:
1) Надо в модели пользователей реализовать три метода, которые определены в интерфейсе UserInterface
В миграцию для пользователей добавить поле куда будет писаться токен.
Class User contains 3 abstract methods and must therefore be declared abstract or implement the remaining methods (Illuminate\Auth\UserInterface::getRememberToken, Illuminate\Auth\UserInterface::setRememberToken, Illuminate\Auth\UserInterface::getRememberTokenName)
Связанно это с обновлением безопасности в версии 4.1.26 (http://laravel.com/docs/upgrade), где закрывали дыру с похищенными куками. Исправить очень легко:
1) Надо в модели пользователей реализовать три метода, которые определены в интерфейсе UserInterface
public function getRememberToken()
{
return $this->remember_token;
}
public function setRememberToken($value)
{
$this->remember_token = $value;
}
public function getRememberTokenName()
{
return 'remember_token';
}
В миграцию для пользователей добавить поле куда будет писаться токен.
$table->string('remember_token', 100);
Понекропощу немного: Зачем вы на гитхаб залили все, включая папочку вендор и composer.lock? Это ужасно, композер создан именно для того чтоб мусор не держать на цвс серверах, все зависимости можно подтянуть в любом месте одной командой.
Sign up to leave a comment.
Laravel. Установка, настройка, создание и деплой приложения