ну и когда canvas будет работать в InternetExplorer? )
не совсем верно сравнивать растровый канвас с векторной графикой - он не включается в дом модель, нет отслеживания событий по отдельным элементам - только вручную... это просто другой, параллельный путь развития, пока хуже поддерживаемый.
ааа!.. это была наиболее впечатлительная моя игра на 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 может быть удобнее.
не совсем верно сравнивать растровый канвас с векторной графикой - он не включается в дом модель, нет отслеживания событий по отдельным элементам - только вручную... это просто другой, параллельный путь развития, пока хуже поддерживаемый.
она кардинально отличалась от всех доступных в то время
к этому семплу 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 может быть удобнее.