Сгенерировать getTitle() и setTitle() — прямо великая задача. Вроде бы пустяковая вещь, зато такая полезная.
В Eloquent даже не нужно писать сеттеры и геттеры для простого получения значения из БД.
И что, шаблоны прямо никогда не меняются? Это вы в каком-то зазеркальном мире живете.
Я живу в реальном мире, и писал, что если появятся правки в верстке, программисту не составит труда найти различия. Тем более если верстальщик сидит рядом и сам покажет, что изменилось. Верстальщик не должен даже знать, на чем написана серверная часть. Я не прав? Что ж, тогда грош цена верстальщику, который не знает PHP, Ruby и Питон к примеру. Он же должен знать, как построены скрипты (на каком языке), знать, какой шаблонизатор используется и т.д.
Здешние программисты не ленивые, а эффективные, потому что вместо того, чтобы тратить время на бесполезные миграции, они пишут бизнес-логику.
И именно поэтому я использую Laravel, потому что все что нужно есть либо в нем из коробки, либо в виде готового пакета расширения. И by the way, я не пользуюсь миграциями. А создаю таблицу сразу в БД. Или это тоже за меня должен сделать какой-то робот, прочитав мои мысли, или сосканировав мои схемы с бумажки?
А что, есть фреймворки, которые научились читать мысли разраба и писать код автоматически? Допустим, есть. Сколько усилий будет потрачено, чтобы научить такой фрейм писать код немного по-другому, если он вдруг не полностью устраивает?
Да что вы такое говорите. Нормальный верстальщик должен сам писать шаблон.
И знать программирование и то, как реализованы скрипты программистами? То есть он должен знать, какую переменную сэтит во вьюху программист, чтобы (даже допустим он владеет такими конструкциями, как if и for(each)) ее выводить? Ну бред же. У нас все четко: дизайнер практически ничего не знает о верстке и программировании, верстальщик не умеет рисовать и не умеет программировать на PHP (но знает болеменее JS, на уровне, достаточном для реализации некоторых динамических вещей типо слайдов, например), а программист не умеет рисовать, но знает основы HTML/CSS (ну само программирование понятно), чтобы в нужных местах в верстке, в которой полностью отсутствует «интеллект», наполнить ее смыслом. Нормальный верстальщик верстает так, что сам HTML переделывать не придется, только CSS. Если же меняется сама структура страницы — нужно быть абсолютно неадекватным программистом, чтобы не найти различия.
В нормальных ORM (Propel и Doctrine)
Propel ни разу не юзал, ничего не могу сказать. А вот Доктрина — кромешный ужас. На серьезном энтерпрайзе все раздувается к чертям собачьим. Нагрузки нереальные. Есть опыт написания солидной аппликухи для сети отелей Ramada с использованием Доктрины, никому не пожелаю таких страданий. К тому же что-то смотрю, здешние программисты совсем ленивые. Я тоже ленивый, но не настолько, чтобы поленится написать схему таблиц, будь то на листочке, непосредственно в БД, или в миграции.
На серьезном проекте с кучей бизнес-логики без геттеров-сеттеров далеко не уедешь. Чем этот Eloquent лучше, чем какой-нибудь бородатый Kohana ORM? Синтаксис один в один, как и все проблемы.
Никто не мешает усложнить логику сеттеров/геттеров. Можно например написать getTitleAttribute(), который будет вызван при попытке доступа к $model->title;
Верстальщики за такое на кол посадят.
Вообще-то PHP-дэвелопер пишет блэйдовский шаблон ПОСЛЕ того, как его сверстали верстальщики.
2014 год, а все руками миграции пишем. ОК.
Частично можно автоматизировать, передав дополнительные параметры артизану.
Одним словом, данная статья — не исчерпывающий сборник рецептов и документация Laravel, а лишь в какой-то степени агитация, как уже говорили выше в комментах.
Ну и толку от этого контейнера, если весь фреймворк в статике написан.
Здешняя «статика» называется фасадами, а в основе их — обычные нестатичные классы. Соотв-но эти самые низлежащие классы инстанциируются через IoC. Любой компонент Лараравела заменяется на собственный простым перебиндиванием в контейнере.
Профессионально работаю на PHP примерно с 2007 года. Начинал с pure, потом был Zend. Видел кратце Yii — ужаснулся. А щас просто фанатею от Laravel. На нем все делается настолько просто и быстро, причем вполне красиво. Уже поднял 3 сайта на нем. Никогда еще не получал большего удовольствия от кодинга, чем щас на Laravel. На все задачи, которые у нас возникают, быстро находим решения на Laravel. Это мое краткое впечатление от фреймворка, подробнее здесь писать не буду, так как очередной холивар на тему «Какой фреймворк лучше» не нужен.
Почти полностью узнал себя, хоть я не очкарик и не тощий =) Был период, когда я выбирался из этого «занудства» в свет, много общался, путешествовал. Но мне это надоело и долгий отход от привычной стези сильно ударило по психике, и я стал еще большим психом — с еще большим рвением погрузился в мир комьпьютеров =) Не могу сказать, что я зануда, но снова «выбираться в свет» меня не тянет — каждому свое. Я насмотрелся на других и нашел свой путь, и безумно счастлив этому =)
До "Code Bright" я пока не дошел (хотя уже купил). В свою очередь могу вкратце резюмировать "Laravel: From Apprentice to Artisan" Тэйлора.
Начинать изучать Laravel можно и с нее (ну и документацию на сайте никто не отменял). В книге в основном описан IoC, лежащий в основе фреймворка с примерами. В заключительной части книги подробно расписывается SOLID дизайн. Весьма позновательно.
Во-первых, RSA и AES — это никакой не велосипед.
Во-вторых, я же написал в конце, что делать, если вдруг RSA и AES не устраивают. Если лично вам по душе больше GPG — флаг в руки. А эта статья не только о том, как непосредственно юзать RSA+AES. А о том, как это можно организовать в Laravel'е.
В-третьих, если бы я написал все с точность наоборот (в смысле юзал GPG), нашелся бы тоже человек, который бы посчитал, что я изобрел велосипед, ведь есть phpseclib.
В-четвертых, phpseclib идет из коробки, в то время как gnupg нужно ставить дополнительно, и не факт, что на вашем хостинге он вообще будет.
И, наконец, в-пятых — о вкусах не спорят.
Лицензия — это частный случай. Здесь проверка лицензии только в качества примера. Какими данным клиент будет обмениваться с сервером зависит от приложения.
В Eloquent даже не нужно писать сеттеры и геттеры для простого получения значения из БД.
Я живу в реальном мире, и писал, что если появятся правки в верстке, программисту не составит труда найти различия. Тем более если верстальщик сидит рядом и сам покажет, что изменилось. Верстальщик не должен даже знать, на чем написана серверная часть. Я не прав? Что ж, тогда грош цена верстальщику, который не знает PHP, Ruby и Питон к примеру. Он же должен знать, как построены скрипты (на каком языке), знать, какой шаблонизатор используется и т.д.
И именно поэтому я использую Laravel, потому что все что нужно есть либо в нем из коробки, либо в виде готового пакета расширения. И by the way, я не пользуюсь миграциями. А создаю таблицу сразу в БД. Или это тоже за меня должен сделать какой-то робот, прочитав мои мысли, или сосканировав мои схемы с бумажки?
Как уже писал в ответ товарищу ниже: что, программисты настолько тупые, что не смогут найти различия в верстке?
А что, есть фреймворки, которые научились читать мысли разраба и писать код автоматически? Допустим, есть. Сколько усилий будет потрачено, чтобы научить такой фрейм писать код немного по-другому, если он вдруг не полностью устраивает?
И знать программирование и то, как реализованы скрипты программистами? То есть он должен знать, какую переменную сэтит во вьюху программист, чтобы (даже допустим он владеет такими конструкциями, как if и for(each)) ее выводить? Ну бред же. У нас все четко: дизайнер практически ничего не знает о верстке и программировании, верстальщик не умеет рисовать и не умеет программировать на PHP (но знает болеменее JS, на уровне, достаточном для реализации некоторых динамических вещей типо слайдов, например), а программист не умеет рисовать, но знает основы HTML/CSS (ну само программирование понятно), чтобы в нужных местах в верстке, в которой полностью отсутствует «интеллект», наполнить ее смыслом. Нормальный верстальщик верстает так, что сам HTML переделывать не придется, только CSS. Если же меняется сама структура страницы — нужно быть абсолютно неадекватным программистом, чтобы не найти различия.
Propel ни разу не юзал, ничего не могу сказать. А вот Доктрина — кромешный ужас. На серьезном энтерпрайзе все раздувается к чертям собачьим. Нагрузки нереальные. Есть опыт написания солидной аппликухи для сети отелей Ramada с использованием Доктрины, никому не пожелаю таких страданий. К тому же что-то смотрю, здешние программисты совсем ленивые. Я тоже ленивый, но не настолько, чтобы поленится написать схему таблиц, будь то на листочке, непосредственно в БД, или в миграции.
Никто не мешает усложнить логику сеттеров/геттеров. Можно например написать getTitleAttribute(), который будет вызван при попытке доступа к $model->title;
Вообще-то PHP-дэвелопер пишет блэйдовский шаблон ПОСЛЕ того, как его сверстали верстальщики.
Частично можно автоматизировать, передав дополнительные параметры артизану.
Одним словом, данная статья — не исчерпывающий сборник рецептов и документация Laravel, а лишь в какой-то степени агитация, как уже говорили выше в комментах.
Здешняя «статика» называется фасадами, а в основе их — обычные нестатичные классы. Соотв-но эти самые низлежащие классы инстанциируются через IoC. Любой компонент Лараравела заменяется на собственный простым перебиндиванием в контейнере.
Начинать изучать Laravel можно и с нее (ну и документацию на сайте никто не отменял). В книге в основном описан IoC, лежащий в основе фреймворка с примерами. В заключительной части книги подробно расписывается SOLID дизайн. Весьма позновательно.
P.S. уже 4к+ подписчиков у хаба, радует…
Во-вторых, я же написал в конце, что делать, если вдруг RSA и AES не устраивают. Если лично вам по душе больше GPG — флаг в руки. А эта статья не только о том, как непосредственно юзать RSA+AES. А о том, как это можно организовать в Laravel'е.
В-третьих, если бы я написал все с точность наоборот (в смысле юзал GPG), нашелся бы тоже человек, который бы посчитал, что я изобрел велосипед, ведь есть phpseclib.
В-четвертых, phpseclib идет из коробки, в то время как gnupg нужно ставить дополнительно, и не факт, что на вашем хостинге он вообще будет.
И, наконец, в-пятых — о вкусах не спорят.