Почему нам нужен был два разных подхода в ATG-pull (капля) и push-based (formhandlers)?

Question

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

У нас есть два подхода mvc, используемых в ATG (или многих других фреймворках), основанных на тяге и на основе push. Как я понимаю, формальщики и капелька играют роль контроллера в разных потребностях, репозитории - это наша модель, а jsps предоставляют представления. И если я прав до этого момента, то какая цель решает цепочка сервлетов? вписывается в эту картину MVC?

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

Большое спасибо перед специалистами. Пожалуйста, помогите.Я не мог найти такого рода объяснения в любом месте.

Answer 1

Первое, что нужно помнить с помощью ATG, - это старая платформа. Поэтому, пытаясь понять различные механизмы с помощью объектива MVC, помните, что ничто не было спроектировано с учетом MVC - платформа предшествует широко распространенным знаниям и признанию шаблона MVC в веб-разработке.

Капельки - это обобщенный механизм для вызова кода Java из шаблона JSP (и ранее, JHTML). Ближайшим аналогом в J2EE-land будет библиотека тегов. Поэтому вы можете использовать их для выполнения множества различных задач. Вы также можете использовать их как MVC-контроллер бедного человека. Это делается путем кодирования пользовательского класса капли, предназначенного для обработки бизнес-логики вашей страницы, и установки соответствующего состояния страницы в качестве параметров запроса. Затем вы вызываете капельу в качестве первого шага на странице JSP. Это не сильно отличается от J2EE-модели 2 с нечетной причудой, которую сначала выполняет ваш скомпилированный JSP, затем вызывает ваш «контроллер», а затем возобновляет обработку «представления».

Обработчики форм, как указано в названии, предназначены для обработки форм. Они выполняются по ссылке в конвейере сервлетов (DAFDropletEventServlet), прежде чем страница, которая была отправлена, начнет рендеринг. Типичное использование обработчиков форм заключается в том, что они отправят перенаправление после выполнения и отменит отображение страницы, что прервет дальнейшую обработку конвейером сервлета. Обработчики форм являются наиболее близкими к «контроллеру» ATG. Но они ужасны для обработки запросов GET и приводят к некоторым очень неудачным URL-адресам, когда используются для этой цели.

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

Answer 2

ATG, на уровне визуализации страницы, не является MVC. Не смотрите на него как MVC. ATG, по своей сути, является расширением базового API сервлета.

Формы и обработка форм, с successUrl и errorUrl - вид MVC. Капель конечно нет.

Это вполне приемлемо в приложении ATG быть выборки данных, поскольку страница рендеринга (т.е. DROPLETS)