Для каких целей используется директория upload/?

IvanRobot: зависит от того что вы хотите сделать. Можете лить в images если хотите. Я вообще на другой сервак картинки лью частенько.

Macbook Pro 13" (2015) для разработки ОК?

sorry_za_tupoi_quest: да

Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

copal: все статьи "создателя MVC" как бы в публичном доступе.

heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

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

Но много интереснее читать более зетализированную публикацию от 2003-его года: heim.ifi.uio.no/~trygver/2003/javazone-jaoo/MVC_pa...

Macbook Pro 13" (2015) для разработки ОК?

sorry_za_tupoi_quest: я говорю о коммерческой разработке в команде. Но до нее вам еще путь предстоит не малый.

Для каких целей используется директория upload/?

IvanRobot: а чем администраторы/контент-менеджеры не пользователи?

Любые файлы, которые являются частью контента (а картинки товаров - это контент) лежат в директории uploads

Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

copal: статью стоит переименовать. Все же речь о separated presentation а не конкретно о MVC. MVC - это одна из первых реализаций этой идеи. И нет, MVP/MVVM не вытекают напрямую из MVC, ибо... все что их объеденяет это конечная цель - разделение логики обработки данных от презентационной логики.

Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

copal:

Компонент это то что можно уже включить и оно будет работать.

Вспомните MVP, там компонент это как раз таки presenter + view (причем иногда не одно вью). Так же и MVVM - там компонент это ViewModel + View.

Хотя я еще подумаю над этим, ибо мой пример с ListView несколько ломает мою же логику на данный момент... Пожалуй продолжим когда я смогу более конкретно рассписать этот пример, возможно я и в самом деле не прав.

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

Так, я разобрался что вы называете ассетами, уже неплохо.

База это просто хранилище, обычное, так же как и хранили данных на уровне кода, как например vo.

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

Меня больше смущает вот что... все что не логика - то презентационная логика... Логика оперирует каким-то данными которые имеют какое-то представление (int, string, VO)...

Давайте тогда вспомним времена ДО GUI и т.д. Ситуация была точно такая жа. а ввод/вывод информации обеспечивали механизмы потоков (стандартные потоки ввода/вывода).

И тут я слегка теряюсь в вашей интерпритации.... Пожалуй проще всего будет сделать так... Я на днях нарисую UML диаграмку простенького приложения, и обрисую там "паттерны" которые будут получаться а так же границу их влияния. На конкретике пожалуй будет меньше путаницы как минимум с моей стороны.

Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

copal: немного уточню. Под "недопониманием" я подразумеваю то что я не могу понять в вашей точке зрения. Ну мол вроде выглядит правильно но что-то не так.

В целом я думаю будет прикольно "нарисовать" то о чем я говорю в виде UML диаграмки какого-нибудь простенького приложения состоящего из нескольких скринов.

p.s. На самом деле если вы думаете что для меня ваши мысли пустой звон - это не так. Я уже кое чего переосмыслил в процессе беседы а стало быть оно уже не бесполезно.

Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

copal:

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

Именно! Я где-то говорил что это имеет хоть какое-то отношение к MVC? Я как раз таки хотел сконцентрировать внимание что приложение это обычно чуть по сложнее чем тупо модель. Там за моделью еще много чего интересного происходит.

У нас выходит конфликт только в том, как мы понимаем слово "модель". Для меня "модель" - это абстрактная штука, которая имеет свою зону ответственности. то есть в контексте какого-то скрина моделью может быть анемичная шляпа, DTO если хотите, которая наполняется другими объектами (о которых презентационная логика ничего не знает и знать не хочет, и потому это вне контекста MVC).

Представление это все что составляет не бизнес логику.

И вот я кажется понял корень недопонимания, хотя немного не уверен. Для вас база данных это представление? Ну мол по сути верно - это "информационная модель", представление данных в каком-либо виде. Для меня же "информационная модель" это второстепенная деталь реализации, то как бизнес логике удобнее оперировать данными. Да и помимо бизнес логики, представления у меня есть еще такая штука как инфраструктура. База данных например к ней относится.

Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

copal: не не не, сам компонент это не MVC, это только VC (контроллер либо как медиатор либо как активная вьюшка в случае презентеров и вью модель). В этом собственно соль, отделение логики обработки данных(M) от презентационной логики (VC).

Нужно ли запрещать git push origin master -f на уровне репозитория?

Частенько develop ветка не нужна, нужен только стабильный мастер. Под "стабильный" я подразумеваю "все работает", то есть тесты зеленые (иначе в мастер это не попадет), и вы уверены что сделали все в соответствии с требованиями. Если не уверены - значит этому еще не место в мастере.

Правда тут маленькое допущение - разработчики адекватны, все покрыто тестами и разработчики реально знают что делать и главное проверяют то что сделали. Я видел много разработчиков которые выкатывали все на тестирование заведома зная что не доделали или просто не проверяя.

master должен быть всегда готов к деплойменту. Если для этого нужна develop ветка - окей, но она может быть и не нужна.

Как найти пересечение массивов?

Roman: откройте доку по функциям, разберитесь что они делают, а потом проверье что у вас не так. Сходу могу сказать что в моем примере "id" а у вас "ID".

Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

copal:

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

Если что у меня есть опыт работы с системами, где и UI и логика пишутся на одном языке (Dlang, ковырял проект dlangui и пытался сделать свои контролы на opengl когда разбирался с последним)

Все компоненты идут из коробки и уже имеют то что Вы все хотите вынести в model.

Нет, просто у меня "модель" в схеме MVC это не конечная точка, это граница между приложением и UI. То есть если взять старый добрый list view у нас будет объект, который наполняется приложением и используется во view.

Это по Вашему кнопка состоит из html === view, js === model и controller === js и все это вместе компонент.

Перестаньте додумывать за меня, вы не угадали. HTML - пассивная вьюка, стало быть MVC уже не выходит (нужно что-то сверху что бы наполнять состоянием) MVP или MVVM - запросто, а вот классический MVC с вьюшкой только в виде HTML сделать не выйдет. Именно по этому MVC собственно последние лет 20 не очень активно юзается (ибо нет нужды).

То есть в случае с фронтэндом активная вьюшка это что-то что формирует DOM (при помощи шаблонизаторов, или просто руками). Скажем компоненты реакта в этом плане - очень хороший пример активных вьюшек если рассматривать их только с точки зрения рендринга.

В MVVM вьюшка это именно пассивный HTML, а все управление оным выносится во view model. Различие с MVP только в наличии биндингов, что дает чуть другой механизм взаимодействия (хотя тут могу соврать, возможно есть и другие принципиальные отличия). в MVA к примеру роль активного компонента, управляющего пассивными вьюшками отводится адаптеру. Отличие от MVP тут опять же только в том, что адаптер может быть не один, они могут быть вложенными друг в друга, в то время как презентер исключительно один.

На бэкэнде в случае HTTP API например пассивной "вьюшкой" является HTTP. То есть это финальная форма UI через которое происходит взаимодействие. И тут здорово подходит подход с MVA с цепочками адаптеров, которые можно реюзать (мидлвэры). Некоторые еще дали этому подходу чуть другое название - ADR (Action-Domain-Responder), оно уже конкретизирует все это дело.

А у автора mvc компонент это сама кнопка.

Именно.

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

Так я же и не отрицаю. Повторюсь, я разбирался как работают "изнутри" библиотеки для построения GUI. Но это "спрятанная сложность" и ради этого все и затевалось. Что бы полностью отделить UI от приложения, дабы иметь возможности эти UI компоненты реюзать.

Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

copal: давайте так, что такое ассеты? В моем понимании это какая-то специфичная для UI фигня (картинки, иконки, файлы переводов и т.д.)

Как использовать React-time-ago?

Никогда не понимал, зачем юзать реакт внутри ангуляра.

[Юзабилити] Что лучше размещать на первом экране?

Артём: чем меньше действий - тем лучше. Если форма большая - просто разбить ее в визард, это будет не так пугать.

[Юзабилити] Что лучше размещать на первом экране?

мокапы есть?

Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

copal: оукей. Пока от вас я улсшыл только какие-то бредни про задницы макак, кашу про информационную и бизнес модель и про то что MVC это базовая вьюшка а компоненты это просто компоненты.

В моей картине мира все логично (для меня и многих с кем я эту тему обсуждал), в вашей - каша. Если вам так удобно - пожалуйста, живите себе.

Это на самом деле не столь важная тема, важно именно отделение логики обработки данных от презентационной логики, и в вашей и в моей системе координат это отделение происходит, и только это важно.

Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

Bags: приведенная вами статья хорошо иллюстрирует проблему. Не важно как называются вещи (контроллеры, адаптеры, вью модель) а важны отношения между этими объектами, как они работают друг с другом и тд.

Model2 это по сути именно описание архитектуры приложения, и да, оно противопоставляется smartui из Model1, а следовательно многие путают это дело с MVC.

Мы не смогли договориться с товаристчем copal: о том что есть модель в контексте приложения (бизнес модель) и с чем именно взаимодействует UI. В частности copal делит модель на информационную модель и бизнес модель (по сути данные и поведение). Для меня же данные - это деталь реализации модели, и нас должно интересовать только поведение.

Контроллер (или адаптер, или вью модель или презентер) взаимодействуют с моделью отправляя сообщения. Вьюшка может запрашивать данные у модели работая с ее поведением. То есть детали реализации модели сокрыты от UI, но модель может предоставлять "слепки" текущего состояния в том или ином виде. Важно только то, что это состояние представлено в том виде, в котором данные используются в приложении, о презентационной логике модель н вкурсе и не должна быть вкурсе, ибо в этом заключается весь смысл разделения логики обработки данных от презентационной логики.

Как-то так. Это то что я могу сформулировать в краткой форме, но я все еще хочу подумать над трактовками чуть больше и описать это в более понятной форме. Ибо даже если MVC на бэкэнда нет, там есть MVA. И примеры с моделью и разделением обязанностей хорошо подходят для объяснения принципов снижения связанности и почему это важно.

Как лучше реализовать ответ от контроллера при ошибке?

Tsiren Naimanov: кастом + статус код, а для ajax статус код и какой-нибудь json-чик например. Зависит от задачи, но статус код посылается тот который описывает ошибку.