tag:blogger.com,1999:blog-68273632805925329572024-02-08T08:24:51.703+02:00cat **/* | grep яAkshaalhttp://www.blogger.com/profile/05677582369584740657noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-6827363280592532957.post-49431107635304533212008-06-03T23:27:00.001+03:002009-02-22T16:30:04.069+02:00GWT (1.5)Очень странные ощущения. После возни с AJAX'овыми вещами с помощью JavaScript'а, писать клиентский код на Java просто сказка. Если скомпилировалось - значит заработает. Но компилируется не всегда - к этому надо просто привынуть. Например GWT.create принимает в качестве аргумента Class, но не тут-то было. Например код:<br />Class c = MyService.class; // или получено из аргумента<br />MyServiceAsync svc = GWT.create (c);<br />Прервет компиляцию с сообщением "Only class literals may be used as arguments to GWT.create()".<br /><br />Подход к package structure, который вроде как strongly recomended, весьма странен с моей точки зрения. Ну сабпакаджи client и server весьма логичны, но вот сабпакадж public - сомнителен (в него предполагается ложить ресурсы как я понял(?)). Более того, client классы не могут зависить от server классов. Т.е. нельзя ложить интерфейс сервиса в package server - его нужно ложить в пакадж client, а в server'е должна лежать только имплементация этого сервиса. Получается по сути таже tier based архитектура, но только наоборот. В классической (ну той к которой я привык), клиентская часть знает о серверной, но не наоборот. А в GWT'ной модели, как раз наоборот получается: серверная часть пользуется классами из клиентской (наследует интефрейсы которые хочет видеть клиент). Собственно это при желании можно обойти сделав отдельный GWT-Module для какого-то отдельно пакаджа с общими классами.. но это ж делать надо и против recomended structure. Впрочем я с первого же дня забил на эту структуру и разложил все по своему - главное понимать, что делаешь и тогда все работает.<br /><ad></ad><br />Сервисы-сервлеты в Module.gwt.xml не прописываю. Заюзал spring-mvc: прописал в web.xml его диспатчер, а в app context'е прописываю сами сервисы-контроллеры (для spring-mvc они контроллеры, а для gwt они сервлеты, а для клиента они сервисы). Получилось красиво весьма. Пока нравится.<br /><br />По уровню boilerplate'ности напоминает EJB 2.1.Akshaalhttp://www.blogger.com/profile/05677582369584740657noreply@blogger.com0tag:blogger.com,1999:blog-6827363280592532957.post-48254958294286461172008-05-28T22:10:00.001+03:002009-02-22T16:28:50.937+02:00Flash, JavaFX, Silverlight, FlexВ эпоху достаточной конкуренции среди одинаковых веб услуг, появление модного слова AJAX показало, что пользователи хотят видеть веб сайты не просто информативными, но с красивым гуевым интерфейсом. Осознав это, компании, практически одновременно, принялись "первыми" выкидывать на рынок или просто разрабатывать новую технологию которая непременно же должна заменить HTML и сделать internet application'ы не просто Rich, а как я услышал в одном докладе на SUN'вской конференции прямо таки Filthy Rich! И все это под open source. Ну прям таки не жизнь, а мед грядет. За что я люблю веб over обыкновенное приложение (пусть оно хоть трижды filthy like a whore):<ad></ad><br />1. Любую вэб страницу я могу отмасштабировать (увеличить или уменьшить шрифт).<br />2. Выключить стили мега дизайнера нахрен.<br />3. Сохранить отдельную страницу.<br />4. Поставить ссылку на отдельную страницу.<br />5. Вернуться на пару страниц назад.<br />6. Окно можно растянуть или сжать не в ущерб содержимому. При этом браузер все красиво переформатирует.<br />7. И т.д.<br /><br />Все это конечно же можно реализовать и плагином, но я уверен, что 90% RIA сайтов делать этого не будут. Короче все это бред и лажа. По крайней мере в том виде в котором оно сейчас есть в виде флэша или ему подобных технологий.<br /><br />Что я точно не понимаю, так это стратегию компании SUN. Ну ладно, хрен с ними с апплетами. Проипали они это поле битвы. Но почему бы в джава плагин не встроить нативно API для интеграции с DOM и Javascript? Модифицировать DOM дерево страницы браузера вроде бы можно, но я так и не нашел, читая javadoc, способа, как например из java повесить свой java handler для onclick или другого event'а какого-то узла этого DOM дерева. Сдается мне, что все на что хватает интеграции из коробки - удалять/добавлять узлы DOM дерева. Есть сбоку LiveConnect, но во первых он сбоку. А во-вторых что с event'ами сходу не понятно, но вроде как есть надежда. Ну чтож, хрен с ними с евентами, может что-то и получилось бы. НО!! Компания САН уже несколько лет не в состоянии выпустить плагин под 64 битные платформы (с 2004го кажется)... и обещают они выпустить java plugin к 2009г. Какие нахрен апплеты, какие RIA..?<br /><br />А всего-то. Была бы в джаве вместо всей этой мега-графической мега-херни для создания мега-никому-не-нужных-грязных-апплетов возможность работать с деревом DOM и событиями - небыло бы необходимости в виде костылей GWT (компиляция из ограниченного сабсета Java в Javascript), потому как это java код напрямую бы работал и делал все, что сейчас делается на JS. Те же GWT виджеты и т.д. все бы было, но с отладкой прям в браузере, мониторинг по JMX и прочие прелести разработки и отладки java standlone, но в вебе. Такое чувство, что в сан только и могут языком трепать и евангелистов разбрасывающих дюков по миру катать.<br /><br />А пока пойду попробую GWT 1.5rc1...<ad2></ad2>Akshaalhttp://www.blogger.com/profile/05677582369584740657noreply@blogger.com0