|
|
|
AntonSaburov |
|
||||
Штурман Профиль Группа: Модератор Сообщений: 5658 Регистрация: 2.7.2002 Где: Санкт-Петербург Репутация: нет Всего: 118 |
Давай не будем обсуждать продукт, который ты знаешь не очень хорошо (возможно я ошибаюсь - тогда можно устроить дискуссия на эту тему в отдельном топике). Можно конечно оценивать дизайн по-разному, но вот для примера сайты на WebSphere Portal. Оба сайта мало используют самописные приложения - большая часть сделана с использованием стандартных возможностей портала. Весь материал само собой в CMS и есть несколько морд - обычная, мобильная и для терминалов. http://www.teachforamerica.org/ - Teach for America http://www.admhmao.ru/ - тут из-за пробем с железом иногда тормозит.
Там несложно увидеть jQuery Но это уже проблема разработчика сайта - если руки кривые, то тут ничего не поможет. |
||||
|
|||||
Vasay |
|
||||||
Эксперт Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 3 Всего: 73 |
Вопрос 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 -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
||||||
|
|||||||
AntonSaburov |
|
||||
Штурман Профиль Группа: Модератор Сообщений: 5658 Регистрация: 2.7.2002 Где: Санкт-Петербург Репутация: нет Всего: 118 |
Если хочется поспорить о порталах - в отдельный топик
Почитай тут - http://www.javatalks.ru/ftopic32853-0-asc-0.php - там очень хорошо разложено что и как по поводу Grails. |
||||
|
|||||
Vasay |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 3 Всего: 73 |
Темы про порталы в свое время я тут создавал. И темы про Java технологии, непригодные для WEB, но активно туда продвигаемые. Но я превосходно понимаю зачем нужен WebSphere Portal и почему Ваша компания его так любит, но этот вопрос к программированию отношения не имеет и затрагивать его тут я вообще не хочу.
Я читал эту тему. Реально толковые посты там пишет Староверъ. А негатив возникает тогда, когда берут команду Java разработчиков, которые никогда не видели Grails, и сажают писать проект на Grails. Вот и прет негатив. Да есть минусы, но есть и плюсы. И часто + Grails сильно перевешивают. Да Grails нишевый продукт -в нем есть смысл когда нужна скорость разработки RoR или Django но в Java среде с интеграцией с другим Java проектами и технологиями. -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
AntonSaburov |
|
|||
Штурман Профиль Группа: Модератор Сообщений: 5658 Регистрация: 2.7.2002 Где: Санкт-Петербург Репутация: нет Всего: 118 |
Я для обсуждения открыл тему - 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 в том, что при работе в команде описываются интерфейсы взаимодействия модулей и никто не лезет в чужой модуль. Важно, чтобы данные передавались точно по спецификации. Если же они не могут быть определены точно (а с динамической типизацией это просто невозможно), то гробится куча времени на отладку и дальнейшее сопросвождение. Или это оспаривается ? |
|||
|
||||
Vasay |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 3 Всего: 73 |
Дальнейшее обсуждение Groovy и Grails перетекло в ту тему С первыми двумя сложно спорить - это цена которую приходится платить. Но плюс Groovy на другими динамическими ЯП в том, что платить ее можно только там, где она оправдана, применяя в остальных местах Java. Насчет третьего - не сталкивался с такой проблемой. Они могут быть определены точно. За исключением случаев когда есть смысл не определять конкретно типы передаваемых значений (тогда пишется Doc). AntonSaburov, попробуйте Groovy, Вам еще понравится Для некоторых задач он очень удобен. И применять его можно только там, где он нужен. Это сообщение отредактировал(а) Vasay - 6.9.2012, 01:00 -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
AntonSaburov |
|
|||
Штурман Профиль Группа: Модератор Сообщений: 5658 Регистрация: 2.7.2002 Где: Санкт-Петербург Репутация: нет Всего: 118 |
||||
|
||||
Vasay |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 3 Всего: 73 |
Если говорить о Groovy, то его вполне можно включить уже в существующий проект. Хотя, конечно, для начала лучше "потренироваться на кошках", т.к. пока не набьете руку будете часто натыкаться на грабли с динамической типизацией, что для рабочего проекта недопустимо. По своему опыту внедрения Groovy в проекты web-crawler-ов могу сказать - что это положительно сказалось на скорости разработки и почти никак не сказалось на скорости их работы - т.к. основная нагрузка приходится на стандартные библиотеки написанные на Java. -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
AntonSaburov |
|
|||
Штурман Профиль Группа: Модератор Сообщений: 5658 Регистрация: 2.7.2002 Где: Санкт-Петербург Репутация: нет Всего: 118 |
Это в каком смысле ? Индексирование веб-сайтов ? Любопытно. |
|||
|
||||
Vasay |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 3 Всего: 73 |
Различный сбор статистики. Самой разной, от простой, для SEO анализа: - Используемый CMS - Исходящие ссылки - Коды бирж продаже ссылок До сложной - для маркетингового анализа активности "черных маркетологов" на различных форумах и блогах. Это сообщение отредактировал(а) Vasay - 6.9.2012, 13:51 -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
AntonSaburov |
|
|||
Штурман Профиль Группа: Модератор Сообщений: 5658 Регистрация: 2.7.2002 Где: Санкт-Петербург Репутация: нет Всего: 118 |
Т.е. кроулится сайт по всяким мнешним проявлениям - хидерам, кукам и прочим радостям - и собирается статистика на него ?
|
|||
|
||||
Vasay |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 3 Всего: 73 |
Для сборки информации о CMS нужно искать некоторые признаки этой CMS. Например, ставящиеся именно этим движком куки, очень надежный метод - проверить существование URL админки (там обычно и название и версия CMS написаны) Исходящие ссылки - просто перебор страниц сайта и сохранение в базу исходящих ссылок. Ресурсоемкая задача. Основная сложность - заставить быстро работать базу. Коды бирж продаж ссылок - тут по определенным признакам. Особой точности, конечно, не добиться. С маркетинговым анализом сложнее и интересней. Но вообще это отдельная тема. Суть сводится к автоматическому выявлению очагов распространения дезинформации для быстрого реагирования. Вообще - выбирая себе что-то, не особо доверяйте "общественному мнению" но форумах и блогах - оно зачастую создано искусственно. Это сообщение отредактировал(а) Vasay - 6.9.2012, 18:36 -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
igilfanov |
|
|||
Новичок Профиль Группа: Участник Сообщений: 30 Регистрация: 4.10.2011 Репутация: нет Всего: нет |
Да совершенно верно. С другой стороны крсивый контент сопряжен огромным числом файлов в т.ч. css и png и при подходе построения многостраничного приложения вижу минус в значительной задержке по времени при загрузке очередной страницы. Но при этом разработка и поддержка проекта проще и быстрее. Например я использую в своем проекте Dojo — свободную модульную библиотеку JavaScript. Был опыт одностраничного приложения с использованием данной библиотеки, при данном подходе приложение работает молненостно, но зато без ссылок подобно http://www.gapa.de/Garmisch_Partenkirchen_...terkuenfte_book, хотя никто ни разу не предъявил притензий по этому поводу так, как это было корпоративное web-приложение. Также было затрачено очень много времени на создание виджетов, а это в свою очередь создание своей уникальной архитектуры. Я пришел к выводу, что все же нужно использовать подход многостраничного построения приложения. Но не сплошь и везде как устроено по умолчанию в Grails. Например для перехода на конкретный сервис (список+форма) нужна ссылка, но когда работаем с элементами сервиса (переход к форме редакт, фильтра, переход к очередной странице gridа), тут уже излишне. |
|||
|
||||
Vasay |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 2097 Регистрация: 8.3.2006 Репутация: 3 Всего: 73 |
Не думаю, что это актуально при современных скоростях интернета. Для WEB приложения это не "излишне". Это необходимость, иначе поисковый робот дальше первой странице не пойдет. Не сможете сохранить ссылку или передать ее по ICQ на конкретную страницу. п.с. мой опыт работы, как обычного пользователя, с web-приложениями перегруженными JS, говорит о том, что чем больше JS тем хуже юзабилити. Админку GoDaddy я вообще вспоминаю как страшный сон. Сейчас все больше и больше расстраивает яндекс.почта. Вот сейчас в опере у них глюк - вставляешь e-mail из буфера обмена в поле получателя - а он при отправке пишет - введите адрес получателя. Да и вообще фигню они с полем адреса сделали - неудобно. -------------------- Придумать идеальную защиту от дурака невозможно, дураки, наудивление, изобретательны. |
|||
|
||||
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | Java: Groovy & Grails | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |