Может войдёшь?
Черновики Написать статью Профиль

Комментарии Proger_XP

Автор исходной статьи «Автозагрузка пространства имён в Laravel 5.3» решил её выпилить, так что не ищите...

Ellrion

Видимо я его всё же обидел, так как он удалил не только ту статью, но и свою предыдущую, которую многие посчитали полезной. А жаль, такой цели у меня не было.

Да, вот это именно то, что нужно. Подробное описание со ссылками на доки.

ИМХО, вариант с изменением файлов Composer напрямую намного трудозатратней, чем собственно правильное решение — 90% пакетов уже и так на GitHub, у 90% разработчиков там тоже есть аккаунт, поэтому тыкнуть Fork и поменять URL в composer.json это дело двух минут. А через энное число дней, когда уже забыл про свои правки в vendor, не придётся биться головой об стену, пытаясь понять, с чего вдруг всё сломалось, и тратить время на поиски пакета, который внезапно «стал несовместимым»

Ellrion

Спасибо за исправления. Да с грамматикой у меня всегда было плохо. Надо будет давать кому то вычитывать сначала, если буду еще писать.

  1. меня интересовал только вопрос по PATH. с остальным проблем нет.

Вы с августа его не решили? Как насчёт Google? С ходу — первый вопрос на русском SO.

shPATH=$PATH:/path/to/composer/...
export PATH
reimax

нет, уже давно решил. спасибо. как раз на so нашел ответ на вопрос.

  1. P.S. А я так и знал — не получится в MVC по-человечески разнести логику и оформление.

У вас все посты совершенно в одном духе — как раньше было хорошо, как сейчас плохо. Причём без фактов и примеров, просто слова в вакууме.

Какая разница между представлением и логикой, если они пересекаются? Смысл их делить? Тогда уж писать всё в одном файле, как в WordPress, и не заморачиваться модными концепциями.

tmanager

У вас все посты совершенно в одном духе — как раньше было хорошо, как сейчас плохо

Да ладно. Ничего подобного в моём комментарии нет.

Какая разница между представлением и логикой, если они пересекаются?

Никакой. От себя добавлю — они всегда пересекаются. Ну кроме каких-то совершенно «учебных» случаев.

Смысл их делить?

Никакого.

Тогда уж писать всё в одном файле, как в WordPress

Я никогда в жизни не агитировал за WordPress.

и не заморачиваться модными концепциями

Ну почему. Просто модные концепции нужно пробовать на зуб.

  1. Перечисление данных массива, разделенных запятой, когда запятую в конце ставить не нужно

Только есть проблема с пробелами — т.к. у тебя там переводы строки и отступы, то в запятой + пробеле нет смысла, т.к. они и так подставляются. А вот убрать пробелы до запятой ты убрать не сможешь (если не ставить cssfont-size: 0 и т.д.).

Если контекст позволяет, то лучше решать через CSS (исчезает возможность копировать запятую, но иногда это даже полезно):

AlexeyMezenin

Проблем с пробелами «почти нет», много использовал в реальном проекте (не только с запятой). Где-то помню проблема была. Решил тем, что в span обернул. За пример с CSS спасибо.

Вопросы к самому Laravel, который меняет структуру даже в минорных релизах. Перевод официальной документации, просто старой (5.1). Кто хочет помочь обновить — пишите.

  1. Здесь ровно то же самое. Если ты хромой программист — Laravel тебе поможет.

Вы намеренно упускаете из виду стандартизацию? Есть компания, у неё раз в N месяцев меняются кадры (пусть даже раз в год). При этом продукт компании имеет цикл жизни N*10. Итого после каждой смены имеем затраты на изучение новым человеком вашего личного велосипеда. Когда он оправдан — хорошо, но в большинстве случаев это не так.

Используя фреймворк — Laravel или любой другой популярный — таких затрат нет в принципе…

tmanager

Стандартизация — это такая тема, о которой я могу писать до завтрашнего утра. Знаете, как это бывает — любимая тема. Но чтобы поберечь Ваше (да и своё) время, позвольте объяснить, почему я намеренно упускаю ее. Потому что стандартизация в нормальном ее понимании — это результат работы уполномоченного на то органа. Который, прежде чем жахнуть очередной стандарт — хотя бы обсудит его. Ну вот как W3C. А если одна команда зафигачила правила, ни с кем не советуясь — это не стандартизация. Надо искать другое название. Например, нотации Laravel.

Всё, занудство кончилось. Уж простите: я без него не мог. А теперь по существу. Давайте почитаем Ваше прекрасное описание хромой конторы:

Есть компания, у неё раз в N месяцев меняются кадры (пусть даже раз в год). При этом продукт компании имеет цикл жизни N*10. Итого после каждой смены имеем затраты на изучение новым человеком вашего личного велосипеда

То есть компания создать свои нотации не в состоянии. Значит, руководитель разработки назначен поспешно. Ему нужно вернуться на тот уровень, на котором он себя проявил, и понаблюдать за работой хорошего IT-менеджера. Который первое что сделает — составит нотации.

Работа руководителя — не только орать и материться, как ни странно это звучит для многих.

Достаточно ли для команды разработчиков нотаций Laravel-a?
У меня нет и тени сомнений, что нет, недостаточно. Доказательство у меня перед глазами — увы, не могу показать Вам. Не имею права. Я про проект, который принял. Так вот. С вот этим: затраты на изучение новым человеком личного велосипеда — никаких проблем. И не только на мое изучения Ларавела. Но и на то, по каким моделям и таблицам разбросана информация. Благо, незатейливая. Но если что посерьезней — никакой Лаправел не спасет.

Так что признайтесь: Вы явно погорячились, написав: Используя фреймворк — Laravel или любой другой популярный — таких затрат нет в принципе.
Советую переформулировать.

  1. Во всей литературе именно V из MVC на русском переводят как представление и реже вид. А конкретный файл это шаблон.

Когда я писал «в большинстве случаев их используют», то имел в виду их применение в повседневной речи (хотя бы и здесь на форуме), а не литературе. Там же, где сейчас засилье «вью».

  1. Что касается пыхи с 5.4 и this, то остались статические анонимки.

Да, действительно, про них я забыл…

Но термин представление нравится или нет является устоявшимся когда мы говорим о слое View из MVC. Не нравится он, ну можно использовать Вид еще.

"Представление"/"вид" действительно режут слух, т.к. в большинстве случаев их используют для обозначения конкретного, гм, представления (разметки/страницы/...), т.е. шаблона, а не для обозначении V в MVC. Учитывая это лучше уж привычные, хотя и не всегда корректные "шаблон" или "макет", чем "лэйаут" или "вью".

Почему же в доке они используются то один то другой и очень вольно? Потому что в php все анонимные функции реализованы через класс Closure (Замыкание).

В большинстве (всех?) распространённых веб-языках…

tmanager

Но это такие тонкости...

Когда-то в прошлой жизни я занимался наукой (успел даже диссер защитить). И в те годы было четкой разделение: «научная статья» и «научно-популярная статья». Считалось, что когда доводишь научное знание для массового читателя, то допускается для блага этого читателя отступить от строгости. Особенно это касается студентов.

То есть если документации называют то, что передается в Route, замыканиями — то в статье для начинающих (а адресат статьи указан в самом начале) лучше и назвать их замыканиями — чтоб не было совершенной лишней «спотыкачки».

Меня вполне устроит, если человек благодаря моей статье выйдет из паники и начнет работать, не вполне понимая разницу между замыканиями и анонимными функциями.

P.S. Но лямбду убрал. Ellrion не зря старался.

Смысл работать в офисе при такой обстановке в стране? Даже при хорошей обстановке офис сильно ограничивает и зависимость от «дяди» спокойствия не добавляет.

tmanager

Английский хромает у меня :( Исправляюсь потихоньку.

Назад | ДальшеДвижется на Habravel