Comments 28
>Для подобных систем век MVC знаконец-то закончился, и слава, как говорится, тебе господи!

По-моему, ничем не противоречит ваша концепция концепции MVC, вы просто выносите часть VC и часть интерфейса к M на клиента. По крайней мере, если приложить некоторые усилия, то JavaScript код можно будет разделить на V и C, а также интерфейс к M
Я с вами не согласен. Так, с большой натяжкой, так можно под MVC подтянуть любую конструкцию.
Выделение слоя модели у вас налицо, функцию log вполне можно считать вьюшкой (она абстрагирует вывод от остальной программы), всё остальное — контроллер (взаимодействие между моделью и вьюшкой) ;)
Хорошо, я объясню, почему я с вами не согласен. Основная разница в терминах и сущностях при помощи которых можно описать и вести разработку. В MVC вы будете строго разделять модель данных от внешнего вида и от обработки данных, что вполне естественно. В нашем же случае мы работаем на уровне взаимодействия интерфейсов. JavaScript программист вполне может быть не в курсе реализации того, что он использует, да и сами RPC вызовы могут возвращать как данные, так и готовое отображение (HTML генерируем и показываем в клиенте — тоже ок!).

В частном случае, конечно, можно подвести эту систему к MVC, но на практике ее возможности гораздо шире. Разрабатывая проект таким способом вы, по сути, сразу же получаете готовое RPC API для его внешнего использования другими приложениями\проектами, чего очень трудно добиться при других схемах разработки.
Так в идеальном MVC взаимодействие осуществляется по интерфейсам, о внутреннем устройстве модели или вьюхи контроллер не знает, а они друг о друге даже не подозревают. А данные всегда хранятся, передаются и возвращаются в каком-то формате, не могут быть «просто данные» в информационной системе, какой это формат JSON, HTML или какой-то бинарный — не суть, особенно при наличии средств инкапсуляции (например нативная поддержка каких-то типов данных в ЯП).

MVC, имхо, не ограничивает возможности никак, она лишь описывает возможную (и во многих отношениях удобную) архитектуру реализаций этих возможностей. Нормальный фреймворк позволяет реализовать классические протоколы RPC с минимальными затратами, а уж вопрос формата представления возвращаемых данных (XML, HTML, JSON, plain tetx, ...) вообще не должен стоять
Будь по вашему — пусть это будет MVC. Тем не менее, речь в статье не о дизайне конечного приложения, а о способе взаимодействия кода внутри него.
Вот, видимо, поэтому мне фраза слух взгляд и резанула. Внутри MVC могут быть различные способы взаимодействия, равно как и какими-то конкретными способами можно реализовать не только MVC. А вы как-то противопоставили… Наверное, что-то конкретное имели в виду.
>Таким образом, я даже не знаю что за модель получилась, но это скорее толстый клиент уже, а не MVC

По-моему эти термины [толстый клиент, MVC] являются вполне непротиворечивыми.
> В нашем же случае мы работаем на уровне взаимодействия интерфейсов.
Противоречия нет

> JavaScript программист вполне может быть не в курсе реализации того, что он использует,
Противоречия нет

> да и сами RPC вызовы могут возвращать как данные, так и готовое отображение (HTML генерируем и показываем в клиенте — тоже ок!).
Тут уже даже не совсем классический толстый клиент получается. Но противоречивости терминов MVC и Thick Client я все равно не вижу.

Так что конкретно мой комментарий вы ничуть не опровергли. Или у меня с логикой не все впорядке, что вполне возможно в день рождения :)
Чем дальше я отвечаю на комментарии, тем больше понятия «тонкий клиент» и «толстый клиент» становятся похожими на «толстого троля» и «тонкого троля». Как я уже написал выше — это статья не о дизайне приложения, а о способе взаимодействия кода внутри него. Спасибо.
> impl/TestUser.inc
Не рекомендуется так скрипты называть.
Лучше *.inc.php
А ещееё лучше — выносить их поверх корня и не нервничать из-за названий. ;)
>>> выбор был не велик
Выбор был ???

Даже если и был, то «PHP-быдлокодинг»-а среди вариантов быть не должно!!!

Он необходим в скоростной разработке (прототипы, презентации, и.т.д.) а в обычной разработке нет такой буквы!!!
Спасибо, мне лично было интересно, а может и пригодится когда. Да, заметил пару опечаток: "(назовем его для приличия aip/Test.php)" и «систем век MVC знаконец-то закончился, и слава, как говорится, тебе господи!»
В extJS есть классная штука — DataProxy и его расширение HttpProxy, которая, в том числе, позволяет делать удобную обработку действий со Store. А то у вас я так понял какой-то свой объект rpc и ServiceProxy, думаю раз уж extJS решили использовать, то стандартные средства сподручней будут.
Автор статьи вроде как Qooxdoo решил использовать. А в extjs есть более близкая «технология», имхо, к тому, что в статье описано — Ext Direct.
Работают ли эти системы с сессиями и позволяют ли разграничивать права доступа к объектам на уровне вызовов их методов?
Что мешает создать объект, наследуемый от HttpProxy или Direct и добавить туда контроль доступа? Последний я правда не использовал, пока не знаю как там что.
Only those users with full accounts are able to leave comments. Log in, please.