Одним из пунктов в «What you get» Тэйлор четко написал, что тем самым мы спонсируем дальнейшую разработку фреймворка. Готов заюзать сервис хотя бы по этой причине :)
Всегда считал, что ORM для того и нужен в том числе, чтобы не заморачиваться с полями из селекта.
А никто и «не заморачивается с полями из селекта». Либо я просто не понял, о каких заморочках идет речь.
Судя по вашему ответу, Eloquent-таки делает вот так SHOW COLUMNS FROM my_table;. Долбить БД однотипными запросами тоже считается хорошей практикой в Laravel?
Не делает он никаких подобных запросов. Ты формируешь запрос разными способами, а он его просто выполняет… Зачем для этого знать схему таблицы? Если ошибка в запросе (например неизвестный column name), то ты ее и получишь от мускуля в ответ.
А причем здесь PHP? Тип поля выставляется для ОРМ.
Не вижу тут особых преимуществ, в Eloquent очень удобно делать различные запросы для выборки. Если же вдруг средствами Eloquent не получается сформировать нужный запрос, есть Query Builder — тоже довольно удобная и мощная штука. Здесь расписывать примеры не буду, если интересует, даю ссылки на документацию с примерами: Eloquent Query Builder
Я конечно понимаю, что о вкусах не спорят. Но от синтаксиса Ruby у меня вынесло мозг, красотой этот язык мой язык (сорри за каламбур) не повернется никогда назвать. Не хочу быть неправильно понятым: я не говорю, что Ruby — говно, нет. Я осознаю его мощь, и в конце концов, именно с RoR'а слизаны многие фишки Laravel'а. Но лично я писать на Ruby не собираюсь.
А зечем Eloquent'у знать схему таблицы? Схему должен знать разработчик, делающий этот селект.
[вангамод]Типов полей конечно же в Eloquent тоже нету, т.е. все время придется руками явно приводить все типы[/вангамод]
А что, PHP у нас оказывается стал строго типизированным языком?
А что, на вашем фреймворке, каким бы он ни был, не существует понятия валидации и фильтрации входящих от пользователя данных, прежде чем пихать их в модель и базу?
И на всякий случай, Ларик понимает поля datetime/timestamp, и в эти поля можно сэтить объект DateTime, либо Carbon напрямую, без format. Как он это делал раньше я не знаю, а щас для таких полей можно явно указать их в списке protected $dates модели. Я предвкушаю агро на эту фразу (ибо это то, что вызывает у вас отвращение, судя по фразе «Или костыль типа protected $available_columns = ['col1', 'col2'];»), но все в этом мире относительно. xml-схему базы можно назвать таким же костылем — тут каждому свое. Посему считаю спор на тему «что лучше, xml-схема с метаданными vs. миграции» не состоятельным, в чужой монастырь со своим уставом не лезут. Где-то кому-то удобнее схемы, где-то кому-то удобнее миграции.
И никогда не было проблем с такими формами, автоматически сгенерированными по метаданным? Типо как какая-то мелочь может не устроить, где нужно чуть подкастомизировать и т.д.?
Я сегодня со своим другом, а по совместительству — начальником, решил обсудить эту тему. У него был опыт разработки сервиса подобного. В чем была суть сервиса я не спрашивал, но он говорил про нагрузки приблизительно в 1000 хитов в секунду. У них делался кэш даже не в секундах, а миллисекундах (для меня была новость, что в некоторые кэш провайдеры так сказать можно передавать не просто секунды (int), а float, то бишь миллисекунды). При этом никому в голову не пришло считать это костылем, что мол приходится милисекунды делить на 1000.
Лично для меня Ларавел является лучшим фреймворком из всех. Но я подчеркну — для меня, я с этим сразу определился, как только начал его копать. Я конечно не стану утверждать, что он лучший в абсолютном смысле, то есть для всех. У каждого свои предпочтения и вкусы. Кто-то ведь считает лучшим фреймворком Yii, в то в ремя как меня от него рвет наизнанку.
Насчет кэша в секундах признаюсь, на этот «косяк» уже несколько раз обращали внимание Тэйлора (автора), в том числе и в нашем русском Laravel-коммьюнити, но он упорно не хочет ничего менять, отклоняя пулл реквесты. Что ж, хозяин — барин. Это пожалуй единственный «косяк» фрейма, по кр. мере о котором мне известно. И то, известно только потому, что для кого-то действительно важно иметь таймауты в секундах. Лично мне даже удобнее, что в Ларике таймаут задается в минутах, так как секундные кэши мне пригождались за всю мою жизнь лишь однажды. Хоть я и программист, но мыслю не в нулях и единицах, секундах и тиках, а в десятичной системе счисления и минутах/часах. Используя секунды мне приходится лишний раз вычислять, сколько требуемый мне интервал будет в секундах. Одним словом, лично я считаю таймауты в минутах только плюсом, так как это более human-фрэндли так сказать.
Насчет покопаться и найти что-то еще «забавное» — тут не знаю. Я уже много внутренностей Ларика перекопал, и нахожу только очень красивые решения и применения современных подходов в программировании. В отличии от все того же Yii, к примеру, где иногда можно аж по несколько классов в одном файле встретить.
О ужас, раз значение таймаута в минутах, то все, однозначно, фрейм говно… На практике, часто ли приходится юзать кэш на секунды? И к тому же, если действительно нужны секунды, можно передать $minutes/60. Есть и другие решения, как например заменить компонент кэша на свой с секундами. Но говорить, что «с фрэмворком все плохо» из-за одной только неустраивающий конкретно вас мелочи неправильно.
Немного не понял задачи. Вообще дропдаун посредством Form делается так:
{{ Form::select('name', $items) }}
Если же имелось ввиду еще дополнительный дропдаун, содержимое которого зависит от выбора в первом, то тут без JS понятное дело не обойтись, и это уже задача не шаблонизатора, а JS.
Не владею подобными терминами, так как универ бросил после первого курса, а теорией никогда не увлекался.
В любом случае, я не понимаю, чем не устраивает запись в шаблоне:
Или смущают вызовы методов объекта Form? Так подстановка PHP-переменной в шаблоне — это тоже код.
P.S. Windows Forms — это уже прошлый век. Щас все на WPF.
Вообще-то рендерить html-форму не в шаблоне — это уже не MVC.
Если вдруг нужно повторение одной и той же формы — делается под-шаблон с ней и инклюдится где нужно.
Готов признать, что по крайней мере частично вы меня переубедили. Как никак, а в споре рождается истина :)
Здесь же Form — это можно сказать helper для генерации элементов форм. Очень удобная штука. К примеру нужно отобразить модель $user с полями допустим nickname и email:
{{ Form::model($user) }}
{{ Form::text('nickname') }}
{{ Form::email('email') }}
{{ Form::close() }}
То есть сгенерятся соотв-но инпуты с проставленными $user->nickname и $user->email. Приятной фишкой также будет, если в бэк-энде будет сделано перенаправление на эту страницу с ->withInput(), то в эти поля проставятся ранее введенные пользователем данные (ситуация, когда пользователь ввел некорректные данные, и бэк-энд вернул пользователя на эту страницу — он увидит введенные ранее данные). То есть сам шаблон лишен логики всякой дополнительной. Все делается в этом хэлпере.
Это красиво звучит в идеальной ситуации. Но зачастую в шаблонах тоже присутствует программерская логика: данные то от бэкэнда получены, но вот вывести их все равно нужно по-особенному. Простейший пример, когда нужно вывести элементы массива в зав-ти от четности-нечетности его нахождения в массиве. Верстальщику придется в какой-то степени уметь программировать, что не вписывается в идеологию полного разделения задач. Ему придется писать foreach, какой-бы шаблонизатор не использовался. Делать проверку на четность и т.д. Или более сложный пример: выводить записи допустим по три на строку. Нужно вести счетчик записей, на каждом третьем закрывать очередной див и открывать новый. В игру входят пускай и простые, но алгоритмы, что накладывает на плечи верстальщика дополнительные требования. А чем меньше требований к кандидату — тем проще его найти.
Вот есть забубенный какой-то верстальщик, и умеет он допустим делать шаблоны для како-нибудь Twig'а допустим. Но так сложилось, что пришлось уволится с текущей конторы. Ищет другую работу: а там либо какой-нибудь Smarty используют, либо вообще все на Zend Framework, но политика компании придерживается этого идеала: верстальщик должен писать шаблоны. В итоге верстальщик должен познать еще и шаблонизацию в стиле Zend и т.п. Ситуация гораздо проще, когда верстальщик делает только то, что вложено в это слово — только верстает. Вот покупаете вы детали конструктора Лего допустим. Вы получили детали, аналог верстки. Теперь вам нужно из них построить домик, аналог фронт-энда. В это дело тоже должен вмешиваться производитель Лего, помогая вам из деталей собрать то, что нужно? Или купили болванку DVD пустую. Вы будете обращаться к производителю, чтобы на нее что-то записать? Сверстанный макет — эта та же болванка, те же детали, из которых можно сделать что нужно. И делать это должен программист. Полное разделение задач: дизайнер предоставляет дизайн, верстальщик предоставляет верстку-болванку с Lorem ipsum'ами, программист прикручивает это к написанному им самим бэк-энду. Дизайнер не знает, как верстать. Верстальщик не знает, как рисовать и программировать. Программист не знает как рисовать и верстать. Но в команде они работают как конвейер, не малозначимое изобретение, если не ошибаюсь, Форда. Можно много аналогий проводить.
У меня большой опыт разработки на PHP, но с вариантом, когда верстальщик сам делает шаблоны, сталкивался всего один раз. Но тут было несколько но: 1) верстальщик четко знал, что писаться все будет на Zend'е; 2) он сам бывший программист. Но даже в этом случае мы теряли много времени на «состыковку»: какие переменные я сэтчу во вьюхи и каков их формат. Когда он не мог достучаться до меня, он сам лез в код и смотрел, а иногда даже что-то правил под удобный ему формат. И это еще хорошо, что основной функционал у меня был готов до верстки. Иначе бы ему приходилось ждать меня, пока я реализую фишку, чтобы он мог ее отобразить. Он сам «настроил» мой код под использование его шаблонов, так как он знал, как назовет файл лэйаута и другие под-шаблоны. Это не дело.
На текущей работе все так, как я считаю и должно быть. Дизайнер --> верстальщик --> программист. Дизайнер нарисовал, отдал, свободен. Верстальщик сверстал, отдал, свободен. А вот программер уже над этим трудится. Верстальщик может отдать верстку до того, как функционал будет готов. Дизайнер же не подстраивается под верстальщика. Так и верстальщик не подстраивается под программиста.
Резюмируя: верстальщик не должен уметь программировать и разбираться серверных языках программирования (не считая желательного для любого верстальщика знания JS); верстальщик не должен разбираться в шаблонизаторах. Он должен просто уметь верстать.
Но это тоже «крайний случай». Конечно неплохо, когда верстальщик «шарит», но возводить это в обязанность неправильно с моей точки зрения. И со мной согласились все мои друзья и коллеги, кстати.
Другими словами, возлагать на верстальщика обязанность подгонять шаблон под бэк-энд — непрактично.
Ну дык речь не идет о том, что разработчик будет верстать. Верстку делает отдельный человек. Тут спор о том, что верстальщик помимо верстки еще и шаблон должен подстроить под бэк-энд, с чем я категорически не согласен.
Я не понял, что вы хотите сказать. Я и парень выше вам хотят сказать, что $article->title — очень-очень плохо, должно быть $article->getTitle(), чтобы это было расширяемо.
Если нужно получить просто данные из БД, то можно получить через $article->title. В этом случае отработает магический метод Eloquent, возвращая значение из внутреннего массива $attributes. Если все таки нужно расширить, что бывает нечасто, то пишется public function getTitleAttribute() {… }; что также имеет «магическую» подоплеку. При этом получение этого поля никак не изменится, это будет по прежнему $article->title;
PHP, Ruby и Питон никто не заставляет учить, но знать шаблонизатор должен
Ну допустим языки знать не должен, что я еще оспорю. Он должен знать все существующие шаблонизаторы? Не говоря о том, что у каждого языка он свой. Главный Программист Вася владеет N шаблонизаторами. Очередной проект он решает реализовать с использованием шаблонизатора k. Верстальщик должен подстраиваться под программиста, и тоже должен знать этот шаблонизатор… Как то много ложится на плечи верстальщика. Идем далее, насчет языков программирования. Вот ВЕРСТАЛЬЩИКУ нужно вывести на странице допустим список новостей. Перед ним встает вопрос: а в какой переменной в шаблоне доступен этот список? Выхода два: либо спросить у программиста, тратя время обоих, либо самому залезьт в код и посмотреть, тратя свое время, но все равно нуждаясь в навыках программирования на этом языке. Далее, допустим список новостей — это массив объектов. Верстальщик должен знать, как 1) обойти этот массив (но допустим он суперски знает все шаблонизаторы и знает как это сделать) 2) как получить значение поля объекта… хм а массив объектов ли это? Или массив ассоциативных массивов? Пожалуй надо опять дернуть программиста и узнать. Либо залезть в код и посмотреть. Допустим объекты. В PHP это будет "->", где-то еще это будет точка. Одним словом без знаний языка не обойтись. И что же? Теперь верстальщик никуда не годен, если он не знает языки. А на кой нам тогда вообще программист, если и верстальщик умеет писать код?
А это значит, что вы не пользуетесь системами деплоймента, дальше даже обсуждать нечего.
Это типо в вас сыграло чувство собственного достоинства? У меня не самые сложные проекты, и хосчу их на обычном shared-хостинге, заливаю файлы посредством FTP, а базу правлю посредством инкрементных SQL-файлов. Или мне обязательно строить из себя продвинутого программиста, используя автоматизированные деплои? На работе мы не юзаем Laravel — у нас свой корпоративный фреймворк. Там мы деплоим автоматом, если что.
Насчет «не использую миграции» я на самом деле погорячился. Просто в большинстве случаев мне быстрее занести изменения в базу напрямую, чем писать новую миграцию. Но при этом я знаю, как работают миграции в Ларавеле и использовал их по-началу. Вполне себе норм. Так и не понял реплику одного человека выше, что мол писать отдельную миграцию для каждого изменения — плохо. Мол «нужно лезть в доку», чтобы посмотреть синтаксис. Уважаемый, а изучая новую технологию, вы тоже без доков обходитесь? Вся инфа приходит во сне сама собой? Ну раз залез в доку, два, обычный человек к этому времени уже запомнит, что нужно. Исходя из этой логики можно сказать, что PHP — гавно, ибо я иногда забываю порядок аргументов какой-нибудь функции, и «приходится всякий раз лезть в доку, чтобы посмотреть синтаксис» (вместо PHP подставить whatever). А как быть с миграциями, которые требуют допустим изменить какое-то поле во всей таблице? Ваш diff схемы тут как-то поможет? Придется писать отдельный скрипт, который все это сделает. А в Ларике это будет просто новая миграция. Случай конечно в моей практике не встречался, но всякое может быть.
Но, собственно, мы несколько отошли от изначальной темы разговора. Вопрос остается открытым: «хотят {{ Form::text('name') }} в стиле Pure (http://purecss.io/), а {{ Form::textarea('bio') }} в стиле horizontal form из bootstrap». Каким образом такое делается?
Да, забыл ответить. Во-первых, как написал выше автор, это можно сделать посредством Form. Во-вторых, никто не заставляет использовать Form, можно написать форму просто «вручную». Сам на двух своих сайтах сделал вполне себе «bootstrap»-формы посредством Form. См. например SBShare.ru
Homestead
Forge
А никто и «не заморачивается с полями из селекта». Либо я просто не понял, о каких заморочках идет речь.
Не делает он никаких подобных запросов. Ты формируешь запрос разными способами, а он его просто выполняет… Зачем для этого знать схему таблицы? Если ошибка в запросе (например неизвестный column name), то ты ее и получишь от мускуля в ответ.
Не вижу тут особых преимуществ, в Eloquent очень удобно делать различные запросы для выборки. Если же вдруг средствами Eloquent не получается сформировать нужный запрос, есть Query Builder — тоже довольно удобная и мощная штука. Здесь расписывать примеры не буду, если интересует, даю ссылки на документацию с примерами:
Eloquent
Query Builder
Я конечно понимаю, что о вкусах не спорят. Но от синтаксиса Ruby у меня вынесло мозг, красотой этот язык мой язык (сорри за каламбур) не повернется никогда назвать. Не хочу быть неправильно понятым: я не говорю, что Ruby — говно, нет. Я осознаю его мощь, и в конце концов, именно с RoR'а слизаны многие фишки Laravel'а. Но лично я писать на Ruby не собираюсь.
А что, PHP у нас оказывается стал строго типизированным языком?
А что, на вашем фреймворке, каким бы он ни был, не существует понятия валидации и фильтрации входящих от пользователя данных, прежде чем пихать их в модель и базу?
И на всякий случай, Ларик понимает поля datetime/timestamp, и в эти поля можно сэтить объект DateTime, либо Carbon напрямую, без format. Как он это делал раньше я не знаю, а щас для таких полей можно явно указать их в списке protected $dates модели. Я предвкушаю агро на эту фразу (ибо это то, что вызывает у вас отвращение, судя по фразе «Или костыль типа protected $available_columns = ['col1', 'col2'];»), но все в этом мире относительно. xml-схему базы можно назвать таким же костылем — тут каждому свое. Посему считаю спор на тему «что лучше, xml-схема с метаданными vs. миграции» не состоятельным, в чужой монастырь со своим уставом не лезут. Где-то кому-то удобнее схемы, где-то кому-то удобнее миграции.
Насчет кэша в секундах признаюсь, на этот «косяк» уже несколько раз обращали внимание Тэйлора (автора), в том числе и в нашем русском Laravel-коммьюнити, но он упорно не хочет ничего менять, отклоняя пулл реквесты. Что ж, хозяин — барин. Это пожалуй единственный «косяк» фрейма, по кр. мере о котором мне известно. И то, известно только потому, что для кого-то действительно важно иметь таймауты в секундах. Лично мне даже удобнее, что в Ларике таймаут задается в минутах, так как секундные кэши мне пригождались за всю мою жизнь лишь однажды. Хоть я и программист, но мыслю не в нулях и единицах, секундах и тиках, а в десятичной системе счисления и минутах/часах. Используя секунды мне приходится лишний раз вычислять, сколько требуемый мне интервал будет в секундах. Одним словом, лично я считаю таймауты в минутах только плюсом, так как это более human-фрэндли так сказать.
Насчет покопаться и найти что-то еще «забавное» — тут не знаю. Я уже много внутренностей Ларика перекопал, и нахожу только очень красивые решения и применения современных подходов в программировании. В отличии от все того же Yii, к примеру, где иногда можно аж по несколько классов в одном файле встретить.
Если же имелось ввиду еще дополнительный дропдаун, содержимое которого зависит от выбора в первом, то тут без JS понятное дело не обойтись, и это уже задача не шаблонизатора, а JS.
В любом случае, я не понимаю, чем не устраивает запись в шаблоне:
Или смущают вызовы методов объекта Form? Так подстановка PHP-переменной в шаблоне — это тоже код.
P.S. Windows Forms — это уже прошлый век. Щас все на WPF.
Если вдруг нужно повторение одной и той же формы — делается под-шаблон с ней и инклюдится где нужно.
Здесь же Form — это можно сказать helper для генерации элементов форм. Очень удобная штука. К примеру нужно отобразить модель $user с полями допустим nickname и email:
{{ Form::model($user) }} {{ Form::text('nickname') }} {{ Form::email('email') }} {{ Form::close() }}То есть сгенерятся соотв-но инпуты с проставленными $user->nickname и $user->email. Приятной фишкой также будет, если в бэк-энде будет сделано перенаправление на эту страницу с ->withInput(), то в эти поля проставятся ранее введенные пользователем данные (ситуация, когда пользователь ввел некорректные данные, и бэк-энд вернул пользователя на эту страницу — он увидит введенные ранее данные). То есть сам шаблон лишен логики всякой дополнительной. Все делается в этом хэлпере.
P.S. Хабр странно отформатировал код х_Х
Значит ему приходилось работать с «тупыми» верстальщиками =) Ибо тут все очень даже просто.
Вот есть забубенный какой-то верстальщик, и умеет он допустим делать шаблоны для како-нибудь Twig'а допустим. Но так сложилось, что пришлось уволится с текущей конторы. Ищет другую работу: а там либо какой-нибудь Smarty используют, либо вообще все на Zend Framework, но политика компании придерживается этого идеала: верстальщик должен писать шаблоны. В итоге верстальщик должен познать еще и шаблонизацию в стиле Zend и т.п. Ситуация гораздо проще, когда верстальщик делает только то, что вложено в это слово — только верстает. Вот покупаете вы детали конструктора Лего допустим. Вы получили детали, аналог верстки. Теперь вам нужно из них построить домик, аналог фронт-энда. В это дело тоже должен вмешиваться производитель Лего, помогая вам из деталей собрать то, что нужно? Или купили болванку DVD пустую. Вы будете обращаться к производителю, чтобы на нее что-то записать? Сверстанный макет — эта та же болванка, те же детали, из которых можно сделать что нужно. И делать это должен программист. Полное разделение задач: дизайнер предоставляет дизайн, верстальщик предоставляет верстку-болванку с Lorem ipsum'ами, программист прикручивает это к написанному им самим бэк-энду. Дизайнер не знает, как верстать. Верстальщик не знает, как рисовать и программировать. Программист не знает как рисовать и верстать. Но в команде они работают как конвейер, не малозначимое изобретение, если не ошибаюсь, Форда. Можно много аналогий проводить.
У меня большой опыт разработки на PHP, но с вариантом, когда верстальщик сам делает шаблоны, сталкивался всего один раз. Но тут было несколько но: 1) верстальщик четко знал, что писаться все будет на Zend'е; 2) он сам бывший программист. Но даже в этом случае мы теряли много времени на «состыковку»: какие переменные я сэтчу во вьюхи и каков их формат. Когда он не мог достучаться до меня, он сам лез в код и смотрел, а иногда даже что-то правил под удобный ему формат. И это еще хорошо, что основной функционал у меня был готов до верстки. Иначе бы ему приходилось ждать меня, пока я реализую фишку, чтобы он мог ее отобразить. Он сам «настроил» мой код под использование его шаблонов, так как он знал, как назовет файл лэйаута и другие под-шаблоны. Это не дело.
На текущей работе все так, как я считаю и должно быть. Дизайнер --> верстальщик --> программист. Дизайнер нарисовал, отдал, свободен. Верстальщик сверстал, отдал, свободен. А вот программер уже над этим трудится. Верстальщик может отдать верстку до того, как функционал будет готов. Дизайнер же не подстраивается под верстальщика. Так и верстальщик не подстраивается под программиста.
Резюмируя: верстальщик не должен уметь программировать и разбираться серверных языках программирования (не считая желательного для любого верстальщика знания JS); верстальщик не должен разбираться в шаблонизаторах. Он должен просто уметь верстать.
Но это тоже «крайний случай». Конечно неплохо, когда верстальщик «шарит», но возводить это в обязанность неправильно с моей точки зрения. И со мной согласились все мои друзья и коллеги, кстати.
Другими словами, возлагать на верстальщика обязанность подгонять шаблон под бэк-энд — непрактично.
Впрочем, тут не буду навязываться. В этом вопросе я действительно не силен.
Если нужно получить просто данные из БД, то можно получить через $article->title. В этом случае отработает магический метод Eloquent, возвращая значение из внутреннего массива $attributes. Если все таки нужно расширить, что бывает нечасто, то пишется public function getTitleAttribute() {… }; что также имеет «магическую» подоплеку. При этом получение этого поля никак не изменится, это будет по прежнему $article->title;
Ну допустим языки знать не должен, что я еще оспорю. Он должен знать все существующие шаблонизаторы? Не говоря о том, что у каждого языка он свой. Главный Программист Вася владеет N шаблонизаторами. Очередной проект он решает реализовать с использованием шаблонизатора k. Верстальщик должен подстраиваться под программиста, и тоже должен знать этот шаблонизатор… Как то много ложится на плечи верстальщика. Идем далее, насчет языков программирования. Вот ВЕРСТАЛЬЩИКУ нужно вывести на странице допустим список новостей. Перед ним встает вопрос: а в какой переменной в шаблоне доступен этот список? Выхода два: либо спросить у программиста, тратя время обоих, либо самому залезьт в код и посмотреть, тратя свое время, но все равно нуждаясь в навыках программирования на этом языке. Далее, допустим список новостей — это массив объектов. Верстальщик должен знать, как 1) обойти этот массив (но допустим он суперски знает все шаблонизаторы и знает как это сделать) 2) как получить значение поля объекта… хм а массив объектов ли это? Или массив ассоциативных массивов? Пожалуй надо опять дернуть программиста и узнать. Либо залезть в код и посмотреть. Допустим объекты. В PHP это будет "->", где-то еще это будет точка. Одним словом без знаний языка не обойтись. И что же? Теперь верстальщик никуда не годен, если он не знает языки. А на кой нам тогда вообще программист, если и верстальщик умеет писать код?
Это типо в вас сыграло чувство собственного достоинства? У меня не самые сложные проекты, и хосчу их на обычном shared-хостинге, заливаю файлы посредством FTP, а базу правлю посредством инкрементных SQL-файлов. Или мне обязательно строить из себя продвинутого программиста, используя автоматизированные деплои? На работе мы не юзаем Laravel — у нас свой корпоративный фреймворк. Там мы деплоим автоматом, если что.
Насчет «не использую миграции» я на самом деле погорячился. Просто в большинстве случаев мне быстрее занести изменения в базу напрямую, чем писать новую миграцию. Но при этом я знаю, как работают миграции в Ларавеле и использовал их по-началу. Вполне себе норм. Так и не понял реплику одного человека выше, что мол писать отдельную миграцию для каждого изменения — плохо. Мол «нужно лезть в доку», чтобы посмотреть синтаксис. Уважаемый, а изучая новую технологию, вы тоже без доков обходитесь? Вся инфа приходит во сне сама собой? Ну раз залез в доку, два, обычный человек к этому времени уже запомнит, что нужно. Исходя из этой логики можно сказать, что PHP — гавно, ибо я иногда забываю порядок аргументов какой-нибудь функции, и «приходится всякий раз лезть в доку, чтобы посмотреть синтаксис» (вместо PHP подставить whatever). А как быть с миграциями, которые требуют допустим изменить какое-то поле во всей таблице? Ваш diff схемы тут как-то поможет? Придется писать отдельный скрипт, который все это сделает. А в Ларике это будет просто новая миграция. Случай конечно в моей практике не встречался, но всякое может быть.
Да, забыл ответить. Во-первых, как написал выше автор, это можно сделать посредством Form. Во-вторых, никто не заставляет использовать Form, можно написать форму просто «вручную». Сам на двух своих сайтах сделал вполне себе «bootstrap»-формы посредством Form. См. например SBShare.ru