Давай не будем обсуждать продукт, который ты знаешь не очень хорошо (возможно я ошибаюсь - тогда можно устроить дискуссия на эту тему в отдельном топике).
Можно конечно оценивать дизайн по-разному, но вот для примера сайты на WebSphere Portal. Оба сайта мало используют самописные приложения - большая часть сделана с использованием стандартных возможностей портала. Весь материал само собой в CMS и есть несколько морд - обычная, мобильная и для терминалов.

http://www.teachforamerica.org/ - Teach for America 
http://www.admhmao.ru/ - тут из-за пробем с железом иногда тормозит.


Там несложно увидеть jQuery  Но это уже проблема разработчика сайта - если руки кривые, то тут ничего не поможет.

Вопрос JavaPortal-ов я изучал. Идея хорошая, реализация подкачала. При этом пару лет назад, единственным порталом, хоть как-то пригодным для создания web-сайтов был LifeRay портал. Но и он имел ряд недостатков, делающим его применение для web неоправданным.


Насчет Ваших примеров - я быстро посмотрел. И я не вижу там задействование портального функционала. Т.е. портал используется как примитивная CMS. Но зачем ставить для этого тяжеловесный портал, когда можно поставить простенькую легкую CMS? 
Для того что бы:

Неужели портал Ханты-Мансийского имеет такую большую посещаемость? 

Если же попытаться применить порталы по назначению - т.е. размещать на страницах не только статичный контент, но и портлеты, то тут мы натыкаемся на грабли:

Одним из важнейших требований к web сайту является соответствие URL контенту. 2 года назад нормальный механизм, позволявший сохранять состояние портлета в URL имел только LifeRay. Но и то реализация была с кучей костылей дававших сбои.
Возможно, с тех пор что-то поменялось.  





Только проблемы, которые есть на этом сайте, свойственны многим фреймворкам, активно использующим JS.
Несколько лет назад самый крупный доменный регистратор godaddy обновил админку - все стало Ajax-ово красиво. Не знаю сколько миллионов $ они на это потратили. Но работать с ним стало невозможно! Потом начались доработки, костыли....   

А если вспомнить продвигаемый в свое время Sun-ом набор компонентов woodstock (слава Богу, канувший в лету) - табличка в 100 строк вешала IE напрочь. 

Я не говорю, что JS плохо. Иногда он очень уместен. Но использовать для WEB JS ориентированные фреймворки ( GWT/ZK/*Faces ) нельзя! Но я вижу, что Java разработчики их очень часто используют. А потом конфликты с заказчиком, когда до того дойдет, какое г в кросивой обертке он получил.

Для WEB нужны фреймворки типа Grails - позволяющие максимально контролировать соответствие URL контенту, сами URL, редиректы. А не GWT/ZK/*Faces и им подобные.

Это сообщение отредактировал(а) Vasay - 5.9.2012, 13:04

Если хочется поспорить о порталах - в отдельный топик 


Почитай тут - http://www.javatalks.ru/ftopic32853-0-asc-0.php - там очень хорошо разложено что и как по поводу Grails.

Темы про порталы в свое время я тут создавал. И темы про Java технологии, непригодные для WEB, но активно туда продвигаемые. 

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




Я читал эту тему. Реально толковые посты там пишет Староверъ. 

А негатив возникает тогда, когда берут команду Java разработчиков, которые никогда не видели Grails,  и сажают писать проект на Grails. Вот и прет негатив. 
Да есть минусы, но есть и плюсы. И часто + Grails сильно перевешивают. 

Да Grails нишевый продукт -в нем есть смысл когда нужна скорость разработки RoR или Django но в Java среде с интеграцией с другим Java проектами и технологиями. 

Я для обсуждения открыл тему - http://forum.vingrad.ru/forum/act-ST/f-113...3/unread-1.html

Добавлено @ 19:28

Потому что он чуть ли ни единственный, кто не хаял Grails ? Хотя и он говорил, что Grails лучше всего подходит для быстрого "сляпать".

Эта подборка фактов не является правдой ?
For the developers 
- No compile time errors when calling missing functions (makes refactoring difficult) 
- Errors only reported at runtime, when the problem occurs 
- Internally, it uses a GString to represent Strings for which the conversion isn't automatic, so you need to do stuff like: "this is a string".toString(); Of course, you don't know you need to do that until runtime and you hit the problem 

Недостаток Grails в том, что при работе в команде описываются интерфейсы взаимодействия модулей и никто не лезет в чужой модуль. Важно, чтобы данные передавались точно по спецификации. Если же они не могут быть определены точно (а с динамической типизацией это просто невозможно), то гробится куча времени на отладку и дальнейшее сопросвождение. Или это оспаривается ?

Дальнейшее обсуждение Groovy и Grails перетекло в ту тему    



С первыми двумя сложно спорить - это цена которую приходится платить.  Но плюс Groovy на другими динамическими ЯП в том, что платить ее можно только там, где она оправдана, применяя в остальных местах Java.

Насчет третьего - не сталкивался с такой проблемой.




Они могут быть определены точно. За исключением случаев когда есть смысл не определять конкретно типы передаваемых значений (тогда пишется Doc). 



AntonSaburov, попробуйте Groovy, Вам еще понравится    Для некоторых задач он очень удобен. И применять его можно только там, где он нужен. 

Это сообщение отредактировал(а) Vasay - 6.9.2012, 01:00

Согласен. Попробовать конечно надо, но когда ... ПРосто читать - это не дело. Надо работать на продукте - тогда будешь его правильно понимать. И зачем и почему и как сделать.

Если говорить о Groovy, то его вполне можно включить уже в существующий проект. 
 
Хотя, конечно, для начала лучше "потренироваться на кошках", т.к. пока не набьете руку будете часто натыкаться на грабли с динамической типизацией, что для рабочего проекта недопустимо. 

По своему опыту внедрения Groovy в проекты web-crawler-ов могу сказать - что это положительно сказалось на скорости разработки и почти никак не сказалось на скорости их работы - т.к. основная нагрузка приходится на стандартные библиотеки написанные на Java. 

Это в каком смысле ? Индексирование веб-сайтов ? Любопытно.

Различный сбор статистики. Самой разной, от простой, для SEO анализа:
- Используемый CMS
- Исходящие ссылки
- Коды бирж продаже ссылок

До сложной - для маркетингового анализа активности "черных маркетологов" на различных форумах и блогах.

Это сообщение отредактировал(а) Vasay - 6.9.2012, 13:51

Т.е. кроулится сайт по всяким мнешним проявлениям - хидерам, кукам и прочим радостям - и собирается статистика на него ?

Для сборки информации о CMS нужно искать некоторые признаки этой CMS.  Например, ставящиеся именно этим движком куки, очень надежный метод - проверить существование URL админки (там обычно и название и версия CMS написаны) 

Исходящие ссылки - просто перебор страниц сайта и сохранение в базу исходящих ссылок. Ресурсоемкая задача. Основная сложность - заставить быстро работать базу. 

Коды бирж продаж ссылок - тут по определенным признакам. Особой точности, конечно, не добиться.


С маркетинговым анализом сложнее и интересней. Но вообще это отдельная тема. Суть сводится к автоматическому выявлению очагов распространения дезинформации для быстрого реагирования. Вообще - выбирая себе что-то, не особо доверяйте "общественному мнению" но форумах и блогах - оно зачастую создано искусственно.


Это сообщение отредактировал(а) Vasay - 6.9.2012, 18:36

Да совершенно верно. 

С другой стороны крсивый контент сопряжен огромным числом файлов в т.ч. css и png и при подходе построения многостраничного приложения вижу минус в значительной задержке по времени при загрузке очередной страницы. Но при этом разработка и поддержка проекта проще и быстрее. Например я использую в своем проекте Dojo  — свободную модульную библиотеку JavaScript. Был опыт одностраничного приложения с использованием данной библиотеки, при данном подходе приложение работает молненостно, но зато без ссылок  подобно http://www.gapa.de/Garmisch_Partenkirchen_...terkuenfte_book, хотя никто ни разу не предъявил притензий по этому поводу так, как это было корпоративное web-приложение. Также было затрачено очень много времени на создание виджетов, а это в свою очередь создание своей уникальной архитектуры.

Я пришел к выводу, что все же нужно использовать подход многостраничного построения приложения. Но не сплошь и везде как устроено по умолчанию в Grails.
Например для перехода на конкретный сервис (список+форма) нужна ссылка, но когда работаем с элементами сервиса (переход к форме редакт, фильтра, переход к очередной странице gridа), тут уже излишне.

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




Для WEB приложения это не "излишне". Это необходимость, иначе поисковый робот дальше первой странице не пойдет. Не сможете сохранить ссылку или передать ее по ICQ на конкретную страницу.


п.с. мой опыт работы, как обычного пользователя, с web-приложениями перегруженными JS, говорит о том, что чем больше JS тем хуже юзабилити. Админку GoDaddy я вообще вспоминаю как страшный сон. 
Сейчас все больше и больше расстраивает яндекс.почта. Вот сейчас в опере у них глюк - вставляешь e-mail из буфера обмена в поле получателя - а он при отправке пишет - введите адрес получателя.  Да и вообще фигню они с полем адреса сделали - неудобно.