ааа!.. это была наиболее впечатлительная моя игра на 286-том! спасибо за пост, такое приятно вспомнить.
она кардинально отличалась от всех доступных в то время
спасибо. Можно реализовать такое исключительна на Dojo - оно как раз и занимается рисованием SVG/VML, GWT - мы используем для удобного написания более сложных веб приложений, чудесная вещь с дебагом! непосредственно java-кода.
к этому семплу GWT-PF не имеет отношения - это наша другая разработка созданная в проектах разработки пользовательского веб-интерфейса к решениям на базе данных. Позволяет легко скручивать и поддерживать типичные формы -справочники со вложенностью: поиск - таблица - просмотр - редактирование, пока нишевое решение - следующая версия как бы есть, но очень поломанная под проект, нужно найти время отрефакторить и выложить, в этой интерфейс плохо гнется, если нужно больше типического справочника.
никак gwt дебагать на опере :\ местами разработки на gwt выходят за предусмотренную "совместимость" с оперой, мы наловили и другие мифические баги в ней... если бы услышать варианты почему не работает? Web Developer Toolbar & Menu for Opera - неюзабелен :\
у меня тоже :) это ведь просто демка, у которой обновление стоит с интералом 30-45мс - браузер не успевает отдавать 25 кадров в секунду. Сделай больше в коде (второй параметр) - будет легче, уже проверено - интервал подобран неудачно )
что ж, спасибо за репорт, пока проблема открыта - легко поймать глюк в опере не удалось. Хотя баг и дикий, к счастью, он не настолько глобален чтобы поломать всю работу, в крайнем случае для оперы нужно будет добавить обработчик-заглушку (гмм?)
думаю будет проще понять, если отмечу, что у нас БД-ориентированные разработки.
Вся основная бизнес-логика не на клиенте, а лежит непосредственно в БД - доступ к данным только через views и сохраненные функции, весь контроль на тригерах и правилах, задачи разделения доступа и поиска в данных решены тоже в БД. И уже вокруг БД идет создания инфраструктуры - и интерфейс пользователя (в котором и используем iBatis) только один с компонентов, причем логики в нем нет. Есть еще формы отчетности в клиенте - но они ходят себе отдельно (jasper, jfree reports, и еще что-то).
не стоит близко воспринимать шутку. Да, Hibernate больше, сложнее и комплексней. Но, не для всех задач хорош - как описал ниже, с "умной" базой клиенту не нужна "умная" ORM. В нашем случаях пришлось бы разрабтывать базы не под надобности логики, а еще и под удобство генерированных Hibernat'ом запросов - это уже не малость накладно.
Не стоит сравнивать апельсин с яблоком - нужно брать все под свои задачи. Даже если большинство программистов пишут, припустим, на java - все-равно легче решить какую-то задачу копирования файлов шел-скриптом.
Для лучшего примера, почему используем iBatis - закинул пост о нашей разработке: http://235.habrahabr.ru/blog/39085.html
В демке можно посмотреть живой пример в коде.
iBATIS - он упрощен только к одной функции - data mapping:
- значительно меньше объемом
- мапит объекты явы в SQL
- проще в использовании и за щет предыдущего очень гибок
Hibernate:
- мапит объекты непосредственно в базу, генерируя при этом свой SQL.
Стоит использовать оба, но естественно под свои задачи. Наши разроботки содержат всю лонику в базе, поэтому никаних сложных запросов нет. Побольше обращения к функциям - даже поиск вынесен в сохраненки, для нас - удобнее, мы их генерируем. Использовать при этом больший и довольно сложный Hibernate - излишек, проще на модель данных завязать 1-5 sql запросов. И при этом не парить голову как помочь ему сгенереривать необходимый запрос - поменше магии, быстрее разработка.
Если же первична не база, как в наших случаях, и вся логика в програме - Hibernate может быть удобнее.
One more note: Offline access is only available in English. We're working on offline access in other languages. It will also be available to Google Apps users soon, and domain administrators that want it now can opt-in via their control panel.
она кардинально отличалась от всех доступных в то время
к этому семплу GWT-PF не имеет отношения - это наша другая разработка созданная в проектах разработки пользовательского веб-интерфейса к решениям на базе данных. Позволяет легко скручивать и поддерживать типичные формы -справочники со вложенностью: поиск - таблица - просмотр - редактирование, пока нишевое решение - следующая версия как бы есть, но очень поломанная под проект, нужно найти время отрефакторить и выложить, в этой интерфейс плохо гнется, если нужно больше типического справочника.
в персональном блоге был пост: http://235.habrahabr.ru/blog/39085.html
вот также прототипчик, более юзабельный с кривыми, следущюю версию пока не выложили: http://gwt.org.ua/ru/odb-ui-demo/
но честно - мне хочется верить, что профессиональные пхп кодеры есть, но в чем я теперь уверен - он должен знать пхп далеко не как первый язык...
сейчас соберем из GWT посвежее, ибо лучше мыслей при первом взгляде не пришло. Опера не перетравила gwt компилят.
Вся основная бизнес-логика не на клиенте, а лежит непосредственно в БД - доступ к данным только через views и сохраненные функции, весь контроль на тригерах и правилах, задачи разделения доступа и поиска в данных решены тоже в БД. И уже вокруг БД идет создания инфраструктуры - и интерфейс пользователя (в котором и используем iBatis) только один с компонентов, причем логики в нем нет. Есть еще формы отчетности в клиенте - но они ходят себе отдельно (jasper, jfree reports, и еще что-то).
Не стоит сравнивать апельсин с яблоком - нужно брать все под свои задачи. Даже если большинство программистов пишут, припустим, на java - все-равно легче решить какую-то задачу копирования файлов шел-скриптом.
В демке можно посмотреть живой пример в коде.
для привязки Hibernate к GWT возможно стоит обратить внимание на http://hibernate4gwt.sourceforge.net/
- значительно меньше объемом
- мапит объекты явы в SQL
- проще в использовании и за щет предыдущего очень гибок
Hibernate:
- мапит объекты непосредственно в базу, генерируя при этом свой SQL.
Стоит использовать оба, но естественно под свои задачи. Наши разроботки содержат всю лонику в базе, поэтому никаних сложных запросов нет. Побольше обращения к функциям - даже поиск вынесен в сохраненки, для нас - удобнее, мы их генерируем. Использовать при этом больший и довольно сложный Hibernate - излишек, проще на модель данных завязать 1-5 sql запросов. И при этом не парить голову как помочь ему сгенереривать необходимый запрос - поменше магии, быстрее разработка.
Если же первична не база, как в наших случаях, и вся логика в програме - Hibernate может быть удобнее.
One more note: Offline access is only available in English. We're working on offline access in other languages. It will also be available to Google Apps users soon, and domain administrators that want it now can opt-in via their control panel.