LINUX.ORG.RU

Про компонентные фреймворки

 ,


0

3

Разобрался с Wicket, написал на нём два небольших веб-приложения, просто в восторге. Это первый раз, когда у меня писанина под веб вызывала минимум отрицательных эмоций, правда особенно много фреймворков я и не знаю, spring mvc, портлеты да всякое самопальное только видел. Но сама концепция компонентности + хранения состояния страниц на сервере позволяет программировать крайне продуктивно, удобно и реюзабельно.

Ещё там аякс просто суперский. Одна строчке на джаве и работает довольно сложная логика.

При всём при этом генерируемый HTML на 99% контролируется программистом, что я очень ценю.

Собственно интересно почитать мнения тех, кто уже работал с подобными фреймворками, их минусы и т.д.

Пока вижу минусы такие: хранение состояния страниц на сервере немного раздувает потребление памяти (надо хранить все страницы, по которым ходил пользователь). Если быть невнимательным со страницами или просто плохо знать, как работает фреймворк, можно легко сериализовать дофига ненужного вместе со страницей (особенно через какой-нибудь хибернейт, который плодит всякие прокси которые бог знает что за собой могут утянуть). Причём инструментов для отслеживания таких ситуаций я, кстати, не нашёл. Хотелось бы иметь возможность каждый раз при сериализации страницы где-то в логи писать дерево сериализованных объектов и размер каждого объекта в байтах. И как то распарсить и показать что лежит в сериализованном на диске page store. Может кто знает что-нибудь такое?

Ещё минус в том, что URL может не отражать смысла страницы, и ручками его не поправишь. Бывает я правлю URL напрямую, например пришёл со страницы поиска на страницу результатов и вместо того, чтобы возващаться назад, можно просто параметр в URL-е поправить. А тут просто /wicket/page?6 ничего не поправить. Правда есть возможность делать bookmarkable pages, передавать состояние руками, но делать так очень не хочется, когда есть возможность делать проще. Даже не знаю, минус или нет, особенность наверное. Да и обычный пользователь в URL наверняка никогда не смотрит и ему плевать, что там написано.

Минусов компонентности я вообще не вижу и не понимаю, как можно после wicket-а писать на чём то другом. Как вспомню, сколько мозголюбства с каким-нибудь банальным <select>-ом по списку значений, с какой-нибудь банальной валидацией.

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

И какие популярные фреймворки подобного рода ещё есть, в том числе в других языках? Именно компонентные, MVC-гадость хочется забыть как страшный сон (я имею в виду всякие контролеры, параметры запроса, атрибуты ответа, да 99% фреймворков по сути обёртки вокруг Servlet-а, дающие небольшой сахарок для парсинга параметров запроса и формирования ответа).

★★★★★

Последнее исправление: Legioner (всего исправлений: 1)

Аякс тоже имеет свои минусы, вся обработка идёт на сервере, дополнительная нагрузка, дополнительные обмены по сети, хотя можно было бы логику продублировать на джаваскрипте и обойтись вообще без аякса

никогда не доверяй стороне клиента.

exception13 ★★★★★
()
Ответ на: комментарий от exception13

Поэтому пишу «продублировать» :) Доверять клиенту нельзя, но добросовестному клиенту ошибку желательно показать пораньше.

Legioner ★★★★★
() автор топика

Реквестирую в качестве примера жизнеспособности Wicket что-нибудь большое и с очень кастомным дизайном.

resurtm ★★★
()

Ещё минус в том, что URL может не отражать смысла страницы, и ручками его не поправишь.

Обыкновенного кастомизируемого роутинга нет? SEOшников-коллег лесом посылать? REST API тоже не сделать?

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

PRADO (PHP) — полностью компонентный.
Yii (PHP) — частично MVC, частично компонентный.

resurtm ★★★
()
Ответ на: комментарий от resurtm

Обыкновенного кастомизируемого роутинга нет? SEOшников-коллег лесом посылать?

Есть, но надо прикладывать специальные усилия. Для определенных страниц сделать несложно, для всего сайта — потеряется весь смысл фреймворка.

REST API тоже не сделать?

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

Legioner ★★★★★
() автор топика
Ответ на: комментарий от Legioner

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

У меня почти в каждом проекте критически необходима возможность легко и просто создавать REST API на сервер-сайде, потому что очень активно использую MV*-подобные клиент-сайд фреймворки (BackboneJS и KnockoutJS). SOAP и WSDL консьюмеры на JS наверное возможны, но звучит как извращение. :-)

Наверное можно сделать, но это определенно не то, зачем он создавался.

Ну да, у него своя ниша решаемых задач. Подойдёт он далеко не каждому веб-разработчику.

Legioner

Это не ты на IDC и Ducat сидел лет 8 назад? :-)

resurtm ★★★
()
Ответ на: комментарий от resurtm

У меня почти в каждом проекте критически необходима возможность легко и просто создавать REST API на сервер-сайде, потому что очень активно использую MV*-подобные клиент-сайд фреймворки (BackboneJS и KnockoutJS). SOAP и WSDL консьюмеры на JS наверное возможны, но звучит как извращение. :-)

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

Это не ты на IDC и Ducat сидел лет 8 назад? :-)

Я :)

Legioner ★★★★★
() автор топика
Ответ на: комментарий от dizza

Есть ли какие-то исследования по этому поводу? У меня субъективное мнение, что 90% пользователей, не являющихся компьютерными специалистами, в URL смотрят только когда хотят набрать начальный адрес сайта (или, в последнее время, фразу для поиска в Google). Firefox рисует URL кроме домена серым, подчёркивая незначительность этой информации. Опера, насколько я помню, вообще не показывает QUERY-часть URL-а, пока не начнёшь редактирование. Получается, что браузеры стараются скрыть URL от пользователя.

Legioner ★★★★★
() автор топика

И какие популярные фреймворки подобного рода ещё есть

Дай угадаю, JSF?

vertexua ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.