Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
какой-то треш. не знаю почему вы считаете что это проще и удобней. я за пхп
А в чем треш?
Вы сможете на пхп сделать то же самое проще и понятнее?
Ну тогда пример кода в студию!
Здесь же изменили поведение существующего щаблона минимальным вмешательством. По моему неплохо.
Надо почитать доки по этому шаблонизатору.
Привлекает что он не портит HTML. А как валидаторы отзываются на шаблоны HTMLki? Кто нибудь пробывал их подсовывать для валидации???
это понятно, как его применять и куда лепить, что-то я вообще по мелочи и не соображу… фрейм только начал изучать…
вот с этим сложнее 
Сейчас стал разбираться, и понял что все не так просто.
Можешь прислать мне код модели в которой ты хочешь реализовать отображение превью?
ЗЫ. В общем после некоторых раздумий пришел к выводу, что самым оптимальным будет следующий вариант: В модели переопределяешь __get(). Если имя атрибута равно ’images’, то отдаешь обернутые тегом <img> данные. Причем имя файла используешь для превью. В остальных случаях просто вызываешь parent. Имхо самый оптимальный вариант.
Как вывести изображений в админке чтоб вместо images: 9421c1f6595b3f5ff0affc2d5ed5a175d128f6eb.jpg была превьюшка которая уже загружена?
Во view надо использовать ImageHelper для вывода нужного размера изображения PHP{{ ImageHelper::getSizePath( $image_name, 'small' ) }}
Как то так. Сам не делал подобного.
Насколько я понял файлы по размерам сохраняются в виде PHP$filename$size/$filename_$size.$ext
Где PHP$size = 'small', в твоем случае
Вообще в ImageHelper всего одна функция. Я думаю разберешься
Печально будет если laravel 4, не будет позволять это все делать, на сколько я понял там бандлов не будет, а библиотеки будут устанавливаться через Composer. Тоже удобно конечно. Но мне как любителю HMVC это не по душе, хотя я думаю гибкость останется и все же получится раскидать это все по отдельным папкам.
А в чем прелесть HMVC?? Во внутренний вызовах? Не вижу смысла заново инициировать весь процесс роутинга и инициализации приложения, если можно напрямую вызвать нужный экшн, который вернет нужный результат. Имхо вообще вызывать экшены из других экшенов не комильфо. Это по умолчанию функции для вызова пользователем. По мне это архитектурная ошибка так делать. Но может быть я чего-то недопонимаю.
Ну и еще вопрос по валидации, есть ли тут возможность вызывать функции которые возвращают не только true|false а которые бы обрабатывали поля как-ниудь. Например. Поле ввода адреса сайта. Оно проверяет есть ли там http:// и если нет то добавляет. А потом я использую что нибудь типа.
$url=$validation->get_value(’url’);
И у меня там уже измененое значение. Ну или чтоб оно сами $inputs редактировало.P.S. Когда уже призы будут самым активным участникам форума)??
Я думаю это не DRY заставлять валицацию изменять входные данные.
Этим должна заниматься модель.
А так никто не запрещал расширять Validator.
В собственных функциях валидации 4 параметром передается this, что дает доступ к свойству $attributes текущего экземпляра Validator. Там и можно менять данные. Потом обращаться к ним через PHP$validator->attributes['attr_name'];
Я где то видел бандл для реализации HMVC. Можно посмотреть в этом направлении.
В start.php добавил строку:
PHPLaravel\Database\Eloquent\Pivot::$timestamps = falseтеперь все хорошо.
Можно конечно и в 1-M\laravel\database\eloquent\pivot.php переопределитьPHPpublic static $timestamps, тоже работает)
Для моих целей поля `created_at` и `updated_at`не нужны вовсе.
Менять код ядра это не совсем ООП подход. Потом забудешь что поменял, и при обновлении версии ядра получишь пляски с бубнами
Первый вариант имхо лучше
На FastCGI действительно многие перешли, связка nginx+php_fpm на моих сайтах дала увеличение производительности в 10 раз по сравнению с Apache+mod_php, как я уже писал выше.
И в этом случае преимущества Phalcon стремятся к нулю
Если учесть, что проектам альтернативных серверов (lighttpd, nginx и пр.) около 10 лет, и они сравнительно недавно стали теснить Apache — то что уж говорить про переход на FastCGI? Принцип «не трогай, пока работает», очень силён, а в некоторых случаях не лишён смысла.
Я к тому, что проблемы 90% сайтов это слой работы с БД. И первым делом оптимизацию надо начинать с этого. А в фальконе этот слой никак не улучшается. И в принципе никак не может быть улучшен.
Код ядра не покроет всех нужд, поэтому по любому будем тянуть свои/чужие модули на PHP, что снижает выигрыш во время инициализации.
Проблемы с инициализацией можно частично победить ядром в виде phar архива. Тогда не нужно будет тянуть кучу файлов при старте скрипта. Ну или fpm. Я просто не вижу задач, которые бы не решались другими способами. А минусы очень явные — усложнение разработки (прежде всего для крупных проектов), усложнение отладки. Зачем мне еще один черный ящик поверх PHP??
Не совсем. В целом любой скрипт, если это не голый PHP с сотней строк в одном файле, работает в десятки раз медленнее отдачи статики самим сервером, что понятно. Такие фреймворки, как Phalcon, пытаются уменьшить эту разницу — не за счёт ускорения выполнения в узких местах (многопоточность), а за счёт повышения общей скорости работы, в данном случае передвинув весь фреймворк (который обычно подключается из скриптов и обрабатывается PHP до того, как собственно сама страница начнёт генерировать содержимое) в уже скомпилированный баайт-код, причём не PHP-шный, а платформенный. Понятно, что скорость инициализации такой страницы стремится к нулю.
Ну если бы инициализация была самым узким местом, то все бы давно на Fast CGI перешли, а этого нет.
И потом код ядра это же еще не все. Будет куча сторонних (или своих) модулей. Их тоже компилировать?
Тогда уж проще Hip Hop PHP использовать.
Ну почему же, очень даже. Касательно Phalcon, там полностью открытый исходный код, скачивайте с github, анализируйте, вносите предложения.
Вот и получается, что для «разгребания» проблем, мне понадобится знание двух языков — С и PHP. А для полноценного тестирования своих «изменений» понадобится постоянная перекомпиляция кода ядра фреймворка. Что несколько усложняет разработку. Также усложняется и отладка. Мне два отладчика одновременно нужно запустить для полноценной отладки. Все идут к тому, чтобы и на сервере, и на фронтенде один язык использовать, а тут наоборот — еще один язык добавляем. Причем компилируемый.
Я не против таких фреймворков. Но тут надо понимать, что ты очень сильно завязан на мастерство разработчиков.
И потом основным узким местом большинства веб-приложений является уровень работы с БД. А это уже модуль, написанный на С. Все остальное — вопрос качества кода и грамотной системы кеширования. Этот фреймворк не дает решений для «узких» мест PHP — асинхронности и многопоточности. Так что я не вижу для чего усложнять себе жизнь.
Я лучше предпочту единую стилизацию кода, автоматическую общую документацию через PHPDoc, прелести автоподстановки и поиска по классам ядра в IDE.
Мне тоже совершенно не понятно, зачем
всю эту мутьеё тянуть — стиль написания совершенно другой, кода в объёме намного больше и его сложнее понять из-за тучи методов getXXX, prepareXXX и т.п. Не спорю, что она может быть более универсальной, в ней меньше ошибок и т.п., но в моих глазах этот аргумент не перевешивает минус за её громоздкость.
Возможно откажутся в поздних версиях. По мне код явно чужероден для Laravel. Надо поднять вопрос на англоязычном форуме.
Спасибо всем за грамотные советы. Теперь для меня кое-что прояснилось. Надеюсь у меня тоже в скором времени будет получатся разбираться в исходниках ядра Laravel.
Да не за что! Надеюсь помогли хоть советы то??
И вообще надо русское сообщество развивать, так что не стесняйтесь задавать вопросы!
Искать решение чужих проблем это тоже способ изучения фреймворка 
Ого, похоже у нас появился участник, который не брезгует заглядывать в исходники Laravel. Так держать
Я в Laravel новичек, поэтому приходится заглядывать. Кстати код прекрасно структурирова и документирован.
Программирую на Kohana, уже привычка выработалась к некоторым решениям. А здесь еще не совсем понял логику разработчиков. Хотя то, что вижу, мне пока нравится.
Вот не совсем понял чем было вызвано решение использовать HTTPFoundation.
PHPpublic function __construct()
{
$this->filter('before', 'auth')->only(array('profile'));
}и тут понеслась: Call to a member function nest() on a non-object, без __construct работает все норма, что может быть?
Чтобы такого не было нужно сначала вызвать конструктор родительского класса. Тогда свойство layout проинициализируется. И все должно заработать
Отменить их для одних, оставив для других, простым образом нельзя, но можно наследовать новый класс отношения has_many_and_belongs_to и в нём перекрыть метод pivot(), который создаёт модель промежуточной таблицы конкретно для этого отношения.
Можно сделать достаточно простым способом. Просто для тех отношений где эти поля нужны, указывать их в явном виде:
return has_many_and_belongs_to->with(array('created_at', 'updated_at'))
А при вставке указывать вторым атрибутом наши поля
$model->many_relation->insert(<массив полей для вставки в модель>, <массив для вставки в Pivot>)
Если в промежуточную таблицу добавить следующие поля:
sql`created_at` datetime DEFAULT NULL, `updated_at` datetime DEFAULT NULL,Но хотелось бы разобраться почему так? Ведь в обоих моделях переопределено свойство
PHPpublic static $timestamps = falseИ таблицы не содержат полей created_at, updated_at. Подскажите как правильно сделать? Нужна ли модель описывающая промежуточную таблицу?
Вот кусок кода из ядра Eloquent:
public function __construct($model, $associated, $table, $foreign, $other)
{
$this->other = $other;
$this->joining = $table ?: $this->joining($model, $associated);
// If the Pivot table is timestamped, we'll set the timestamp columns to be
// fetched when the pivot table models are fetched by the developer else
// the ID will be the only "extra" column fetched in by default.
if (Pivot::$timestamps)
{
$this->with[] = 'created_at';
$this->with[] = 'updated_at';
}
parent::__construct($model, $associated, $foreign);
}
А в модели Pivot по умолчанию стоит
public static $timestamps = true;
Я думаю можно смело поменять на false, даже не заморачиваясь.
Если умеете читать по-английски, тогда вот еще ссылочка на мой блог:
http://maxoffsky.comВот темы которую я пишу на блоге:
Backbone + Laravel
Creating a Laravel blog
Etc,Также вводный курс со множеством бесплатного контента:
http://www.udemy.com/develop-web-apps-w … framework/
Нет планов на русский свой туториал перевести???
Все-таки в рунете дефицит материалов по Laravel
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)