Начинание :). Вы бы на дату посмотрели начала проекта, мы начали когда o Mootools никто и не слышал. И тем более уже столько времени прошло, а у нас имеется уникальный неповторимые фишки. Мне кажется вы бегло прочитали статью. Или Вы наверно большой знаток jQuery, Mootools? Я за вас рад. Ваш разговор на тему: зачем молоцикл, ведь уже давно есть машина. Можете и дальше ездить на машинах. Мотоциклы не ваша стихия. Я бы мог сказать так — нафига придумали .Net — это производный велосипед от Java. Однако я так не скажу, потому что хоть отчасти это и правда, но .Net тоже очень хорошо.
ну реально зацепил вопрос — :) да в jQuery много чего нету, jQuery всегда повторно загружает скрипты которые нашел в запрошенных HTML, всегда повторно их исполняет, надо опять же искать плагины для истории, для разделения запросов по ИД, и т.д. и т.п. jQuery очень хорошо, не не идеально, есть что доработать. В большинстве случаев его хватает с головой, сам им пользуюсь. НО все же…
Причиной использования может удобство при реализации того или иного функционала, или вообще уникальность решения. У меня на кухне стоит набор из ножей и разными ножами я режу разные продукты. Точно так же и на работе. Эта первая статья более обзорная, дальше будет больше практических примеров, после чего вы сможете определить стоит использовать или нет. И в каких именно случаях. Следите за дальнейшими публикация.
Поддержка истории в ExtJS появилась намного позднее чем в нашей разработке. Когда проверял их реализацию нашел несколько багов, особенно в Опере.
Реализация истории в Fullajax другая, отработано много разных тонких моментов, все сразу не описать. Да в более специфических случаях манипулировать историей у нас можно гибче… вообщем надо вам самому попробывать.
загрузите в jQuery страницу c таким содержимым123<script>document.write('456')</script>789
есть и другие примеры.
ну почему же, всегда можно сравнивать что с чем-то просто, главное определить критерии сравнения. В данном случае я хотел подчеркнуть схожесть применения [b]динамического[/b] мапинга объектов в таблицы БД.
Никто и не спорит что реализация такого мапинга у Hibernate на несколько порядков выше. А если учесть что это дело совместно используется со Spring (Transactional, DAO, прочее) + Invocation + Reflection — тогда становится очевидным возможный уровень реализации…
тут народ проявляет больший интерес к диаграмма чем к архитектуре системы :).
Чем-то напоминает ситуацию когда небольшой драгоценный камень вставляют в толстые и тяжелые изделия из драг метала. Получается из-за массы и блеска оправы камня то и невидно…
Предлагаю вам отложить разработку CMS и начать разрабатывать флеш-диаграмы :))
еще раз убеждаюсь что об одном и том же люди думают в одно и тоже время но в разных точках Земли.
мы также используем ORM в нашем сервисе структур данных, но используя для этого Hibenate. Наша реализация запрограммирована на Java и немного сложнее на стороне сервера при создании своих типов, но зато более гибка в последующем при работе с объектами конкретного типа(-ов). Мапинг обьектов осуществляется на основе динамически сгенерированых классов с последующей их загрузкой в runtime. Классы генерируются соответственно на основе данных предоставленых юзером о типе объекта. Для запроса, поиска, удаления объектов используются JSON или SQL подобный синтаксис, который на сервере трансформируется в Hibenate Criteria. Также реализована Lazy («ленивая», по требованию) загрузка свойств объектов.
С учетом того что мы разрабатываем на разных ЯП, рад что кто-то реализовывает чем-то схожую с нами архитектуру работы с объектами.
P.s.: диаграммки чудо! в чем это они сгенерированы?
По поводу кроссплатформенности — хоть убейте не понимаю, ибо сама концепция веб-сервисов как таковых построена на том, что к сервису обращаются «на языке веб-сервисов», а не на языке, на котором написан сервис.
ок, но гораздо удобнее дергать методы объектов, методы прослойки, которая тупо поднимает объект из сервиса (в нашем случае это называется клиент). Зачем сделали DWR? все затем же, проще и удобнее дергатьметоды объектов
Сервисы данных (если я правильно понимаю, что они из себя в Hivext-е представляют) уже давно существуют и как концепция, и как реализация. Те же Adobe LiveCycle Services, Microsoft ADO.NET «Astoria» Data Services и так далее…
Отлично, мы не говорим что мы уникальны в мире, наши конкуренты Microsoft, Google, Amazon.
У каждого есть своя изюминка. Кому-то нравится одно, кому-то другое. У вас сколько продуктовых магазинов в районе? наверно несколько, и в каждом есть посетители, верно?
да, можно сказать что веб-сервисы — это следующий уровень программирования. Т.е. ЯП развивались грубо говоря примерно так: Assembler -> C -> C#. Мы продолжаем цепочку Assembler -> C -> C# -> WebServices (Hivext). Веб сервисы придумали не мы, мы их просто реализовываем видя в них большой потенциал и будущее.
вы близки к пониманию. правильно если вам нужны сервисы с собственной специфической логикой вы их сами и делате. Т.е. вы не паритесь про то что вам надо опять создавать логику входа/выхода, профайл, проверку данных, синхронизацию, прочее… т.е. то, что переходит и проекта в проект, зачем вам постоянно об этом заботится.
Если суть вашего проекта уникальный сервис, так вам надо максимально сконцентрироваться на разработке вашей изюминки. Hivext как раз поможет в этом. Если бы был такой сервис раньше, скорость разработки одного из моих проектов уменьшилась бы в 2-месяцев до 2-х недель. Потому как 70% времени было потрачено на стандартные операции с юзерами, хранением объектов, прочее. Это один из частных примеров.
Но опять же — даже уникальные ваши сервисы можно сделать на основе Hivext сервисов. Когда появится сервис структур вы сможете создавать любые обьекты, сущности, структры, типы. Давайте рассмотрим в чем заключается «цимус» уникальных сервисов: либо в специфических данных, либо в специфическом алгоритме обработки данных, либо в смеси первого и второго. Так вот данные можно хранить на основе Hivext сервисов. По сути вам надо будет только вставить свой уникальный алгоритм в сервисы.
И в заключение: теперь представьте что у вас есть доступ к вашим данным, сервисам по стандартизированному кросс-платформенному АПИ: .Net, Java, JavaScript, AIR, Flash, другое. Достучатся к сервисам можно из любого ЯП. Интерфейс АПИ максмально одинаковый. Ну думаю сами мысль закончите…
в последнее время я часто использую такие вещи как GoogleMap, GoogleVisualzation. Пусть Hivext и не сравнима с ними по функционалу, но зато легко привести пример чтобы стало понятнее что и зачем. Вы представляете как устроена ГИС (GoogleMap)? на бекенде стоит мощный сервер и наверно не один, на котором развернут сервер карт, который в свою очередь дергает БД с разными слоями, картами. все это довольно сложно устроенно. Вы работали когда-то с GooogleMap? Правда приятно и удобно работать? в тоже время вы не заботитесь о серверной стороне, о картах. Вот и Hivext забирает на себя сложность реализации и поддержки серверной части, в коплект которой входят транзакции, кеширование, прочее.
hax — HtmlAjaX
Да именно Fullajax, название действительно родилось самособой — ничего другое так не подходит
кстати еще один проект, который проект который копает в эту сторону
кстати AHAH если прочитать по русски тоже интересно звучит :)
Реализация истории в Fullajax другая, отработано много разных тонких моментов, все сразу не описать. Да в более специфических случаях манипулировать историей у нас можно гибче… вообщем надо вам самому попробывать.
загрузите в jQuery страницу c таким содержимым123<script>document.write('456')</script>789
есть и другие примеры.
Никто и не спорит что реализация такого мапинга у Hibernate на несколько порядков выше. А если учесть что это дело совместно используется со Spring (Transactional, DAO, прочее) + Invocation + Reflection — тогда становится очевидным возможный уровень реализации…
Чем-то напоминает ситуацию когда небольшой драгоценный камень вставляют в толстые и тяжелые изделия из драг метала. Получается из-за массы и блеска оправы камня то и невидно…
Предлагаю вам отложить разработку CMS и начать разрабатывать флеш-диаграмы :))
мы также используем ORM в нашем сервисе структур данных, но используя для этого Hibenate. Наша реализация запрограммирована на Java и немного сложнее на стороне сервера при создании своих типов, но зато более гибка в последующем при работе с объектами конкретного типа(-ов). Мапинг обьектов осуществляется на основе динамически сгенерированых классов с последующей их загрузкой в runtime. Классы генерируются соответственно на основе данных предоставленых юзером о типе объекта. Для запроса, поиска, удаления объектов используются JSON или SQL подобный синтаксис, который на сервере трансформируется в Hibenate Criteria. Также реализована Lazy («ленивая», по требованию) загрузка свойств объектов.
С учетом того что мы разрабатываем на разных ЯП, рад что кто-то реализовывает чем-то схожую с нами архитектуру работы с объектами.
P.s.: диаграммки чудо! в чем это они сгенерированы?
Отлично, мы не говорим что мы уникальны в мире, наши конкуренты Microsoft, Google, Amazon.
У каждого есть своя изюминка. Кому-то нравится одно, кому-то другое. У вас сколько продуктовых магазинов в районе? наверно несколько, и в каждом есть посетители, верно?
Если суть вашего проекта уникальный сервис, так вам надо максимально сконцентрироваться на разработке вашей изюминки. Hivext как раз поможет в этом. Если бы был такой сервис раньше, скорость разработки одного из моих проектов уменьшилась бы в 2-месяцев до 2-х недель. Потому как 70% времени было потрачено на стандартные операции с юзерами, хранением объектов, прочее. Это один из частных примеров.
Но опять же — даже уникальные ваши сервисы можно сделать на основе Hivext сервисов. Когда появится сервис структур вы сможете создавать любые обьекты, сущности, структры, типы. Давайте рассмотрим в чем заключается «цимус» уникальных сервисов: либо в специфических данных, либо в специфическом алгоритме обработки данных, либо в смеси первого и второго. Так вот данные можно хранить на основе Hivext сервисов. По сути вам надо будет только вставить свой уникальный алгоритм в сервисы.
И в заключение: теперь представьте что у вас есть доступ к вашим данным, сервисам по стандартизированному кросс-платформенному АПИ: .Net, Java, JavaScript, AIR, Flash, другое. Достучатся к сервисам можно из любого ЯП. Интерфейс АПИ максмально одинаковый. Ну думаю сами мысль закончите…