Comments 22
Что за ерунда? Вы вызываете контроллер во вью?
Если задача была сделать вложенность шаблонов, то есть куча способов это сделать не таким глупым способом.
Хотя бы написать какой-нибудь класс Layout, реализовать в нём Компоновщик и рендерить этот Layout с нужными данными.
Если задача была сделать вложенность шаблонов, то есть куча способов это сделать не таким глупым способом.
Хотя бы написать какой-нибудь класс Layout, реализовать в нём Компоновщик и рендерить этот Layout с нужными данными.
И вы даже не эскейпите данные, которые получаете из суперглобального массива. Привет XSS и SQL Injection.
Пример он и в африке пример. Очевидно, же, что в примере опущено все лишнее…
Это не совсем тот ресурс, где такое прокатит.
В любом случае MVC это суперзаезженная тема, а у Вас далеко не самая удачная и, главное, не самая удачная реализация. Потому что придраться, честно говоря, можно не только к небезопасным данным, а к странному именованию классов, игнорированию каких-либо принятых стандартов и CS'ов.
В любом случае MVC это суперзаезженная тема, а у Вас далеко не самая удачная и, главное, не самая удачная реализация. Потому что придраться, честно говоря, можно не только к небезопасным данным, а к странному именованию классов, игнорированию каких-либо принятых стандартов и CS'ов.
И тут я с Вами не совсем согласен, увы. По моим понятиям, ни один нормальный разработчик никогда не возьмет код чужого примера в свой проект без изменений. Я, по крайней мере, такие попытки у членов своей команды пресекаю очень жестко. Пример должен максимально четко, ясно и прозрачно показывать архитектурную идею, или технический прием. Так, чтобы разработчик мог легко понять и взять эту идею. Сделав, разумеется, собственную реализацию. И как раз публикаций, которые отвечали бы таким условиям очень мало. Особенно в том, что касается архитектурных решений. Например меня, как потенциального читателя, очень мало интересует как автор назвал класс, или перемекнную. Я все равно назову по своему… Меня интересует как взаимодействуют части системы. Есть ли какой-то простой подход, которого я не знал раньше? Могу ли я за счет материала статьи упростить код и уменьшить его количество? ИМХО это как раз самое важное. Согласны?
Э-э-э. Вызов контроллера (возможно другого, не того, который сейчас проводит рендеринг) из View — как раз распространенная практика. Намного проще, и разумнее, чем писать компоновщик. Такой подход широко используется в рамках системы Razor. Например:
stackoverflow.com/questions/21155574/mvc-calling-controller-from-view
Не уверен, что эту систему стоит считать глупой и рекомендую изучить ее архитектуру более пристально… А вот в PHP такой подход использзуется незаслуженно редко.
stackoverflow.com/questions/21155574/mvc-calling-controller-from-view
Не уверен, что эту систему стоит считать глупой и рекомендую изучить ее архитектуру более пристально… А вот в PHP такой подход использзуется незаслуженно редко.
Такой подход используется редко, потому что раскидывать вызовы контроллеров по View, дак ещё и
Предлагаемая система может послужить неплохим скелетом для реализации сложных приложений.— это как минимум выйдет огромный, неподдерживаемый монстр. Поэтому я считаю это ерундой.
Такой подход широко используется в рамках системы Razor. Например: stackoverflow.com/questions/21155574/mvc-calling-controller-from-view
Во-первых, Razor — это не система, а движок шаблонов в asp.net.
А во-вторых, то, что происходит по вашей ссылке — это компоновка через вызов Action (не важно, это вызов через AJAX, или через механизм partial actions), и здесь важно понимать, что в этом случае происходит обработка всей триады MVC.
С замечанием по поводу Razor — соглашусь. А теперь давайте попробуем разобраться с триадой MVC. Полностью согласен с тем, что при вызове partial actions она отрабатывает полностью. И это с моей точки зрения невероятно сильное место ASP. Почему я считаю это сильным местом?
1. Обеспечивается возможность вести сквозную разработку «от представления». Каждое представление само запрашивает у системы нужные данные
2. Обеспечивается возможность легкого внесения изменений в архитектуру и функционал системы, путем замены буквально одной строчки в представлении. Это можно сделать заменив вызов одного partial action на вызов другого.
По сути, в моем примере и была сделана реализация чего-то аналогичного. Кстати, в моем примере также при вызове задействуется вся триада. И контроллер, и модель, которая создается в рамках вызова action, и другое представление. Вся триада на лицо. Разве нет? Более того, если мы говорим о partial action. В примере заложен механизм, позволяющий легко сделать надстройку для пост-обработки данных рендеринга. Функция handle включает захват выходного буфера и записывает его в переменную. Очевидно, что в нормальной реализации системы содержимое этой переменной должно не просто выкидываться функцией echo, как сделано в примере, а проходить пост-обработку через устанавливаемые фильтры. Например для вырезания только нужного участка. Понятно, что иметь в качестве шаблонов непонятные участки html-кода, как сделано в примере, не есть хорошо. Делать такую нарезку — слишком трудоемкая задача. Другое дело, что такие вопросы мне казались абсолютно самоочевидными и не заслуживающими подробного разбора
1. Обеспечивается возможность вести сквозную разработку «от представления». Каждое представление само запрашивает у системы нужные данные
2. Обеспечивается возможность легкого внесения изменений в архитектуру и функционал системы, путем замены буквально одной строчки в представлении. Это можно сделать заменив вызов одного partial action на вызов другого.
По сути, в моем примере и была сделана реализация чего-то аналогичного. Кстати, в моем примере также при вызове задействуется вся триада. И контроллер, и модель, которая создается в рамках вызова action, и другое представление. Вся триада на лицо. Разве нет? Более того, если мы говорим о partial action. В примере заложен механизм, позволяющий легко сделать надстройку для пост-обработки данных рендеринга. Функция handle включает захват выходного буфера и записывает его в переменную. Очевидно, что в нормальной реализации системы содержимое этой переменной должно не просто выкидываться функцией echo, как сделано в примере, а проходить пост-обработку через устанавливаемые фильтры. Например для вырезания только нужного участка. Понятно, что иметь в качестве шаблонов непонятные участки html-кода, как сделано в примере, не есть хорошо. Делать такую нарезку — слишком трудоемкая задача. Другое дело, что такие вопросы мне казались абсолютно самоочевидными и не заслуживающими подробного разбора
Обеспечивается возможность вести сквозную разработку «от представления».
Это, заметим, не очень хорошая идея сама по себе, потому что она может противоречить развитию бизнес-сценария.
Обеспечивается возможность легкого внесения изменений в архитектуру и функционал системы, путем замены буквально одной строчки в представлении. Это можно сделать заменив вызов одного partial action на вызов другого.
Архитектура у вас не меняется совершенно. Да и функциональность системы в целом — тоже не очень. Вы просто играете в заранее предложенные кирпичики.
Кстати, в моем примере также при вызове задействуется вся триада. И контроллер, и модель, которая создается в рамках вызова action, и другое представление. Вся триада на лицо. Разве нет?
Может быть и да, я не разбирался до конца. Я всего лишь констатирую факт — в asp.net MVC в приведенном вами примере происходит не «вызов контроллера», а полная обработка запроса.
По поводу хороша идея, или нет — можно долго ломать копья и устраивать священные войны. На самом деле — каждый архитектор ПО нарабатывает собственные предпочтительные методы построения систем, которые удобны лично ему и соответствуют именно его способу мышления. Каждый из таких подходов имеет свои и сильные стороны, и ограничения. Поэтому, ИМХО, тут спорить просто бесполезно.
Далее. Момент, который Вы, возможно упустили из виду. И в asp.net MVC, и в моем примере, нет прямого обращения к классу контроллера. Есть обращение к системе с просьбой вызвать определенное действие определенного контроллера. И в том, и в другом случае, система вольна произвести замену.
Посмотрите пример внимательнее. Там нет строчки $controller->action. Нет прямого обращения к классу контроллера. Есть обращение $app-> Но, это обращение не к конкретному контроллеру, а к системе в целом. Иными словами, "$app->" примера есть аналог "Html" asp. Жаль, что Вы ведете дискуссию не до конца разобравшись в архитектуре примера.
Далее. Момент, который Вы, возможно упустили из виду. И в asp.net MVC, и в моем примере, нет прямого обращения к классу контроллера. Есть обращение к системе с просьбой вызвать определенное действие определенного контроллера. И в том, и в другом случае, система вольна произвести замену.
Посмотрите пример внимательнее. Там нет строчки $controller->action. Нет прямого обращения к классу контроллера. Есть обращение $app-> Но, это обращение не к конкретному контроллеру, а к системе в целом. Иными словами, "$app->" примера есть аналог "Html" asp. Жаль, что Вы ведете дискуссию не до конца разобравшись в архитектуре примера.
Это, на самом деле, не вызов контроллера, а запрос результата действия (action). Разница в том, что Actions — это, своего рода, внешний интерфейс системы, его можно и нужно вызывать откуда угодно.
Верно. Но разве там не указывается имя контроллера, которому принадлежит action? Смотрим строчку: Html.Action(«ActionName», «ControllerName»)
Сравниваем c примером:
$app->handle(«hello»,«say»);
Если назвать метод «handle» примера «Action' и поменять местами имя действия и имя контроллера — в чем будет различие?
Неужели, такие вещи не очевидны?
Сравниваем c примером:
$app->handle(«hello»,«say»);
Если назвать метод «handle» примера «Action' и поменять местами имя действия и имя контроллера — в чем будет различие?
Неужели, такие вещи не очевидны?
Там, конечно, указывается имя контроллера, потому что имя контроллера — это часть запроса.
Я просто указываю на то, что вызов контроллера — это:
и такого в представлении допускать нельзя. А вот обращение через внешнюю часть инфраструктуры — можно, потому что оно ничем не хуже обращения через тот же AJAX (который еще никому не приходило в голову запретить).
Я просто указываю на то, что вызов контроллера — это:
someController->getSomeData()
и такого в представлении допускать нельзя. А вот обращение через внешнюю часть инфраструктуры — можно, потому что оно ничем не хуже обращения через тот же AJAX (который еще никому не приходило в голову запретить).
Возможно, мы в пылу дискуссии не до конца поняли друг друга. Насчет того, что прямой вызов контроллера из представления есть зло я полностью согласен. Представление разумеется должно запрашивать нужные ему данные не в сыром виде, а в виде уже сформированной части представления. Я полностью согласен с Вами в том, что попытка запроса сырых данных породит излишние зависимости в системе и, как всегда в таких случаях, родит неповоротливого монстра. Представление ИМХО может делать только одно из двух. Или получать от модели полностью подготовленный набор данных, или запрашивать у системы уже полностью подготовленный фрагмент представления, годный для вставки в нужное место «as is», без какой-либо дополнительной обработки. В случае такого запроса представление абсолютно не должно знать, как и каким образом этот фрагмент будет сформирован. По моему, тут наши позиции полностью совпадают. Согласны?
Хотелось бы поздравить автора с выходом из комы или возвращением на землю после похищения инопланетянами.
Хотелось бы посоветовать почитать про php 5, про безопасность, про тестирование, про composer, про PSR…
Хотелось бы посоветовать почитать про php 5, про безопасность, про тестирование, про composer, про PSR…
Sign up to leave a comment.
Простая реализация модели MVC с поддержкой иерархии шаблонов