www.w3.org/TR/xslt
с XSLT конечно много ограничений, но зато вы вынесите логику JS на xslt. Вот это уже интереснее.
Здрасте, «клиентская часть так или иначе будет зависеть от логики» вы же как раз от этого и пытаетесь уйти. А получилось все наоборот, давайте начнем с того — что такое вью? и какая роль у JS в вью слое? разве это не логика некоего нового слоя «вью-модель» даже больше «вью-модель-контроллер»?
ммм тут же речь не про «толстяков». Gmail — всетаки хорош наверно. Но gwt технология меня совсем не впечатлила, даже разочаровала. Свингерам наверно будет проще, писать на gwt, но сама архитектура это технологии мне совсем не понравилась(может я недостаточно углубился в ее изучении). Все вперемешку модель-вью-контроллер.
Как-то вы на свой лад дали определение «клиент-сервер» приложений. Чем HTML не ответ на запрос?
Слишком уж сложные узлы архитектуры у вас получились, контролы на JS,… а почему не XSLT?
Вашей архитектурой вы пытаетесь отделить бизнес-логику приложения перенести на сервер, и тут нечего спорить, MVC рулит. Но, тем самым вы породили еще один слой логики (HTML — JS — WebServices) который опять же рулится на клиенте. Вот как раз это и есть «слабое звено» вашей архитектуры.
ммм IBM спецификация изначально была хреновой и мало чем отличалась от JSR-168. Возьмите хотя бы пдф у IBM о разработке портлетов на JSR-168 и IBM спеке. Пол книги один в один, только методы и переменные называются по разному. Единственное за что нужно сказать спасибо, это возможность в PortletData сохранять объекты, а не String'и.
На основе портлетов можно писать приложения со сложной бизнес логикой. Плюс, однажды написав портлет вы его сможете развернуть на новом проекте за несколько минут. И не писать в очередной раз из проекта в проект.
Нет альтернатив насколько я знаю нет, да и зачем? Вы встречали альтернативы сервлетов? Несколько лет назад, когда портлеты только начали развиваться IBM решила пойти своим путем. Она разрабатывала свое API. Ничего хорошего из этого не вышло, проект закрыт. Вообще IBM сервер/портал очень тяжелый. Очень много нагорожено всего, половина апи с дырами, половина управляющих портлетов написано на деприкейтном API. Я бы посоветовал для начала попробовать свои силы с JBoss. Этот портал легче и деплоить проекты проще. А разницы в реализации портлетов нет практически никакой, только xml маппинг.
с XSLT конечно много ограничений, но зато вы вынесите логику JS на xslt. Вот это уже интереснее.
Здрасте, «клиентская часть так или иначе будет зависеть от логики» вы же как раз от этого и пытаетесь уйти. А получилось все наоборот, давайте начнем с того — что такое вью? и какая роль у JS в вью слое? разве это не логика некоего нового слоя «вью-модель» даже больше «вью-модель-контроллер»?
Слишком уж сложные узлы архитектуры у вас получились, контролы на JS,… а почему не XSLT?
Вашей архитектурой вы пытаетесь отделить бизнес-логику приложения перенести на сервер, и тут нечего спорить, MVC рулит. Но, тем самым вы породили еще один слой логики (HTML — JS — WebServices) который опять же рулится на клиенте. Вот как раз это и есть «слабое звено» вашей архитектуры.