Отчего концепции Web-движков, такие страшные, может дело в html?

И? Какой код у тебя еще есть кроме манипулирования данными? Может ты неправильно работаешь с формами и прочим, и вместо кастомного валидатора из трех строк пишешь простыни в контроллере?

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

Смотря какой компонент нужен. Но оверхеда там 0.

ага ссылка в топике, погляди

Ты сам это читал? Там написано совсем не то, что ты говорил.

An important aspect of the original MVC was that its Controller was responsible for creating and coordinating its subordinate views.

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

не иначе как заговор 8), интересно какая корпорация на лоре ввела кавычки?

и в каких фреймворках не многословно? а то я смотрел рельсы, питоначие и тп, везде где mvc - 3 файла с кучей ненужной херни

Мне лень читать

а мне лень отвечать

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

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

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

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

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

а мне лень отвечать

Но ведь я ответил. И ответ мой был, что Js файл подключается в контроллере а не в шаблоне. Потому что у компонента есть свой контроллер. Который и данные может из модели взять кстати.

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

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

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

Приведи пример такой логики? Может ее можно кинуть либо в модель, либо в форму, либо в валидатор, либо в фильтр, ну или еще куда-нибудь.

На практике, если у тебя куча типовых страниц, то делается обертка. Что то типа facelets composition из мира jsf.

An important aspect of the original MVC was that its Controller was responsible for creating and coordinating its subordinate views.

и что не так? creating and coordinating - какраз что рендерить - т.е. ошибку или выдать, например «форму следующего шага регистрации пользователя»

Как бы создание представлений и модификация модели не одно и то же Отчего концепции Web-движков, такие страшные, может дело в html? (комментарий)

везде где mvc - 3 файла с кучей ненужной херни

Никогда на такое не напарывался, только шаблоны в отдельных файлах.

и в каких фреймворках не многословно?

В любых с мощным шаблонизатором (Mako, Jinja2), обработка реквеста везде одинакова, вытягивание данных из модели и скармливание шаблону. Именно поэтому MVC вообще не применим как термин к большинству некомпонентных фреймворков.

И ответ мой был, что Js файл подключается в контроллере а не в шаблоне. Потому что у компонента есть свой контроллер. Который и данные может из модели взять кстати.

а еслиб ты прочитал то увидел бы что там также, но еще _нужно_ дофига кода, а по логике вещей JS и css то детали представления и к контроллеру не должны иметь отношения

Модель в среднем отражает структуру дб, а не структуру страниц.

это болезнь orm-щиков, на практике вся куча из бд соединяется в мегапипец и отдается рендеру чтоб он слил с шаблоном, вот этот мегапипец и догадайся кто.

Приведи пример такой логики? Может ее можно кинуть либо в модель, либо в форму, либо в валидатор, либо в фильтр, ну или еще куда-нибудь.

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

вот код ищущий рейсы - то чему в контроллере не место, и яб посмотрел как он будет в валидаторе сидеть

обертка подходил лишь для навигации, а я ее тебе как пример привел

а еслиб ты прочитал то увидел бы что там также, но еще _нужно_ дофига кода, а по логике вещей JS и css то детали представления и к контроллеру не должны иметь отношения

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

это болезнь orm-щиков, на практике вся куча из бд соединяется в мегапипец и отдается рендеру чтоб он слил с шаблоном, вот этот мегапипец и догадайся кто.

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

DEFINITION
An Editor is an interface between a user and one or more views. It provides the user with a suitable command system, for example in the form of menus that may change dynamically

according to the current context. It provides the Views with the necessary coordination and command messages.

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

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

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

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

И да, в symfony можно так же легко и из представления подключить JS и CSS в нужное место, это дело вкуса.

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

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

если ты можешь достать из бд несколько маленьких и опрятных пипецов и отдать их рендеру?

бгг вот в акте передачи у тебя и совершится порождение мегапипца

так это у тебя подход хреначим код где стоим из первого пункта

Nope. Под навороченностью подразумевалось не полнота по тьюрингу, а возможности по повторному использованию шаблонов.

а контроллер - голый потому что логики нет

Голые контроллеры это прекрасно, прекраснее только их отсутствие.

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

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

Не понял. Там нужна одна строка с функцией типа addStylesheet. Можно вообще в конфиге общим для шаблонов раздела прописать подключение нужных js и css. Я просто не могу увидеть тут проблему.

бгг вот в акте передачи у тебя и совершится порождение мегапипца

Почему? Все данные во view передаются отдельно.

короче скатываемся к тому что лучшая концепция - ее отсутсвие

Почему? Все данные во view передаются отдельно.

разница то какая сразу ты контекст рендеринга напихаешь или потом?

потому что модель рейсов совокупляющаяся с веб сервисами и сервером геоинформации - это маразм делегирования отвественности

Как не заимплементируй, это никакого отношения к html иметь не будет.

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

Где здесь маразм? У нас есть модель рейса, мы можем использовать ее везде. Она делает запросы к веб сервисам и серверу геоинформации, ну и что? Кто сказал, что в модели нельзя делать запросы? Эти запросы даже не добавляют сайд эффектов функции, где здесь проблема вообще?

разница то какая сразу ты контекст рендеринга напихаешь или потом?

Ну допустим у этой страницы есть контроллер, ей передается список постов, текущий юзер, количество уведомлений. Где здесь мегапипец то?

лучшая концепция - ее отсутсвие

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

Тебя так расстраивает, что это не MVC? Зато работает отлично, в отличие от.

У нас есть модель рейса, мы можем использовать ее везде.

ее нет, то что выдается - данные рейса + данные о местах, такого нет ибо ненужно

Она делает запросы к веб сервисам и серверу геоинформации, ну и что?

тебя не смущает что _модель_ (а в твоих привычках это обертка из orm) по сути структура данных, ага, что-то _делает_? Я еще понимаю когда там работа с тойже сраной базой, типа удалить, или допустим «назначить водителя на рейс».

А тут налицо _асинхронные_ запросы к ресурсу который может быть недоступен, мало того, в рейсах нет никакой информации о городах 8)

где здесь проблема вообще?

проблема в дизайне, мой дорогой

Тебя так расстраивает, что это не MVC? Зато работает отлично, в отличие от.

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

_модель_ по сути структура данных, ага, что-то _делает_?

Я не понял почему модель структура данных и кто должен делать запросы к веб-сервисам? Уж не контроллер ли?

ее нет, то что выдается - данные рейса + данные о местах, такого нет ибо ненужно

Почему нет? Мы можем, но не хотим. Не хотим, ну и ладно.

тебя не смущает что _модель_ (а в твоих привычках это обертка из orm) по сути структура данных, ага, что-то _делает_? Я еще понимаю когда там работа с тойже сраной базой, типа удалить, или допустим «назначить водителя на рейс».

Тебя не смущает то, что модель это не структура данных? Я тебе говорил уже про наиболее частые ошибки на странице википедии. Пассивная модель - это лишь один из видов моделей. В современной разработке более популярны активные модели. Это когда модель занимается доступом к данным и так же занимается всей бизнес-логикой. Если тебе не нравится такая концепция, можешь воспринимать подобные модели как просто middleware. Ты же не пишешь алгоритм подсчета хэша в контроллере, так и тут.

тебя не смущает что _модель_ (а в твоих привычках это обертка из orm) по сути структура данных, ага, что-то _делает_?

Что значит что-то делает? Она для того и предназначена.

А тут налицо _асинхронные_ запросы к ресурсу который может быть недоступен, мало того, в рейсах нет никакой информации о городах 8)

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

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

у меня например часто есть RPC, ты его как предлагаешь делать? Шаблонами на json? Или может лучше ввести понятие сервисного слоя/слоя логики/ядра приложения?

Уважаемый subwoofer, предлагаю тебе новую концепцию, называется лапшекод. Суть такова. Есть большой index.php, в нем гигантский оператор switch который обрабатывает данные набигающих запросов. И html и код - все вместе. Можно вставлять что угодно куда угодно. Никаких лишних файлов, все можно всунуть в один файл. Все логично и понятно. Не нужно парится, правильно ли ты делаешь. Я ждвадцать постов назад хотел это написать.

Почему нет? Мы можем, но не хотим. Не хотим, ну и ладно.

мы можем писать все в одном файле index.php, почему нет? Тебяж такой вопрос не беспокоит? Нет, а это следующий уровень.

Тебя не смущает то, что модель это не структура данных?

яж писал уже смущает фаулера, он ее зовет анемичной моделью.

В современной разработке более популярны активные модели.

в современной разработке популярны mvc там где они не нужны 8)

Это когда модель занимается доступом к данным и так же занимается всей бизнес-логикой.

я тебя разочарую то что ты тут мне вещаешь называется http://ru.wikipedia.org/wiki/ActiveRecord а то что щас популярно orm и именно он занимается «доступом»

Ты же не пишешь алгоритм подсчета хэша в контроллере, так и тут.

сделай усилие (не читать шаблоны корпоративных приложений ненадо - не поможет) осиль разницу между внутренне логикой и внешней.

В частности:

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

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

Почему вы не отвечаете на мой ответ? Для json-rpc шаблон не нужен, ты это считаешь ущербностью концепции MVC?

Что значит что-то делает? Она для того и предназначена.

минимальная задача модели - хранить состояние, максимальное god object, у вас гдето рядом с последним

который к вебу вообще никакого отношения не имеет.

имеет тут у товарища веб _только_ из контроллера и модели и он не знает куда засунуть службу рассылки почты.

Уважаемый subwoofer, предлагаю тебе новую концепцию, называется лапшекод.

Отчего концепции Web-движков, такие страшные, может дело в html? (комментарий)

мы можем писать все в одном файле index.php, почему нет? Тебяж такой вопрос не беспокоит? Нет, а это следующий уровень.

в очередь, тем более что я предыдущим постом ответил и на твое петросянство, случайно, я не хотел 8)

у вас гдето рядом с последним

Бгг. В такой постановке у меня бы было по функции на каждый внешний источник данных. На god, а тем более на object это мало похоже.

и он не знает куда засунуть службу рассылки почты.

А не похрен ли? Есть только два хороших критерия:

* насколько быстра и дешева разработка

* насколько просто тестировать.

Так все-таки

кто должен делать запросы к веб-сервисам? Уж не контроллер ли?

я тебя разочарую то что ты тут мне вещаешь называется http://ru.wikipedia.org/wiki/ActiveRecord а то что щас популярно orm и именно он занимается «доступом»

Нет, это совсем не то. Почитай про модели в MVC хотя-бы в википедии. То, что я говорю совсем не относится к ORM.

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

Реализовывать ее с доступом к приватным членам класса что же еще? А если серьезно, может логика быть реализована без доступа к приватным членам класса или нет, какая разница?

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

Потому что там нужно не те плюсы предоставляемые активной моделью, а те, которые предоставляет сервисы приложения? У этих вещей разные сферы применения. Если всё локально, хочешь - делай SOA, хочешь - активную модель. Ты же не будешь делать сервис приложения для того чтобы получать доступ к апи фейсбука. для того, чтобы там расшарить картинку?

почему с вебом такие сложности?

Надуманно. Все работает прекрасно.

Надуманно. Все работает прекрасно.

Внезапно в тред врывается сишечка! С js и вебсокетами xDDD.

С js и вебсокетами xDDD.

И таки скажи, что не работает!