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

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

Я всерьез думал об этом когда ко мне обратилась менеджер Packt с предложением написать самоучитель по Laravel. Много думал и пришел к выводу, что писать очередную книгу смысла нет, а написать книгу для новичков и сразу по ходу объяснять «как правильно делать» ну очень сложно. Человек так устроен, что он не может впитать слишком много информации за короткий промежуток времени, поэтому лучше всего начать обучение с обычной книги для новичков или видеокастов, а уже потом расти. Для меня этот продход работает.

А переучиться не так сложно. Все мы когда-то…

Ed

Убедили, буду продолжать) Благо в гугле почти все можно найти. Хотя с хомстедом промучался долго, несмотря на кучу мануалов по его установке. А еще с Mix, тоже было не просто, т.к. упорно не ставился npm на хомстеде, в итоге стал с ошибками, но скомпилил таки css.

С php было проще, общую логику понял и пишу себе поглядывая в гугле как делается очередной необходимый кусочек функционала. Тут же слишком много всего, куча пакетов с кучей версий, которые не так просто подключить (как было с mix), а главное еще нужно понять какой для чего реально нужен. Много статей прочитал для начинающих, и во многих сказано: «ставим это и то и еще это», а вот для чего не сказано. И в итоге, чтобы запилить «хелло ворлд» папка с проектом вырастает до 200Мб непонятно чего))
Может не учебник, а хотябы упорядоченый, толковый и желательно актуальный (под 5.5) список ссылок на готовые статьи по теме соберете?) Начиная с первой про среду разработки и разбор базовых и реально необходимых доп.пакетов... А то ведь найти можно все, но отличить полезное от вредного в найденном новичку не под силу обычно.

(если честно я не знаю зачем вам тратить на это время, но раз уж вы подобное делаете, я готов нагло воспользоваться)))

Спасибо, точки убрал.

Не уверен на счет размазывания кода, не думаю, что видел такое в приложениях. Наоборот, весь код обычно в контроллерах. В моем примере присутствует размазывание?

Спасибо за дополнение.

Переиспользовать метод можно, ведь в любом случае этот метод зависит от данных в объекте Request. Тестируется это тоже отлично. Плюс же заключается в том, что мы не передает множество данных, а просто внедряем Request. Если бы мы работали с моделью или другими классами, там да, нужно передавать непосредственно данные (массив, создаваемый $request->all()), хотя многие передают объект Request.

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

Если у тебя…

В контрололерах — всю логику.

Это не MVC.

И ты не ответил, ты в контроллере данные будешь итерировать? Т.е. ты в контроллере будешь лепить что-то вроде:

foreach ($page->children() as $child) {
      $a .= '<li>'.$child->title.'</li>';
}

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

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

@foreach ($arrayOrCollection as $value)
    {{ $loop->first ? '' : ', ' }}
    <span class="nice">{{ $value->first_name }}</span>
@endforeach
Proger_XP
  1. Перечисление данных массива, разделенных запятой, когда запятую в конце ставить не нужно

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

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

css.nice + .nice:before { content: ", "; }

Если нет, то нужно ставить запятую после блока, причём без пробелов/новой строки перед ней, а вот это уже не так красиво.

Контроллер имеет минимум логики, от вытягивает данные из модели и передает в представление. Представление — это не только оформление. Перечислять (итерировать) данные ты в контроллере будешь?

tmanager

Ну да. Раз уж пришлось работать в MVC (мне больше нравится мои собственные паттерны, но что делать — не кормят они...) — то очень поможет порядок: где что искать.

В моделях — ищем работу с базой(-ами).
В контрололерах — всю логику.
В представлениях — всё, что относится к вёрстке.

Птоэтому у меня представления короткие и почти лишенные логики. В них — верстка страницы.

Я поддерживабю проект, написанный другими разработчиками. Там представление — это «ад каннибалов». Вот чего я стараюсь избегать.

Да, хороший URL. )

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