Comments 37
Несмотря на то, что сам являюсь поклонником этой библиотеки, не понял, причем здесь jQuery и тем более работа с сервисами.
Это все реализуется прекрасно на любом другом FW (будь то Prototype, mootools и тд) и без них.
И разве скрипт - response уже называется «сервисом»?
Саму же работу с сервисами(если уж такой заголовок) правильнее было бы представить не на взаимодействии через json, а общепринятом языке сервисов-XML (тот же SOAP-стиль), который jQuery также поддерживает.
Это все реализуется прекрасно на любом другом FW (будь то Prototype, mootools и тд) и без них.
И разве скрипт - response уже называется «сервисом»?
Саму же работу с сервисами(если уж такой заголовок) правильнее было бы представить не на взаимодействии через json, а общепринятом языке сервисов-XML (тот же SOAP-стиль), который jQuery также поддерживает.
Я не понимаю, в чем состоит ваше непонимание. С помощью jq в статье вызываются веб-сервисы .Net. Я знаю, что все это реализуется и руками и на любом другом фреймворке, но в этом блоге вроде про jQuery пишут.
>>> И разве скрипт - response уже называется «сервисом»?
Не понял о чем речь. Если вы почитаете статью, то увидите что статья о вызове .net веб-сервисов, которые написаны на c# и используются в asp.net.
>>>Саму же работу с сервисами(если уж такой заголовок) правильнее было бы представить
Я написал статью о том что мне было интересно. Причем тут soap?
>>> И разве скрипт - response уже называется «сервисом»?
Не понял о чем речь. Если вы почитаете статью, то увидите что статья о вызове .net веб-сервисов, которые написаны на c# и используются в asp.net.
>>>Саму же работу с сервисами(если уж такой заголовок) правильнее было бы представить
Я написал статью о том что мне было интересно. Причем тут soap?
тоже не понял, _что_ автор называет сервисами. Да и то, что рассказано в статье абсолютно не привязано к asp.net, тем более на столь примитивном примере.
изменил единственное упоминание asp.net в статье на более другое
Просто вопрос: вы писали на .net веб-сервисы?
посмотрите на интерфейсы того же facebook и все станет на свои места
ну, и причем тут facebook?
Еще раз вопрос: вы писали на .net веб-сервисы?
Еще раз вопрос: вы писали на .net веб-сервисы?
извините, что мешаю, а причем здесь постановка "на .net сервисы"? на то они и сервисы, совершенно безразлично на _чем_ они, java, php или дотнет, для пользователя сервисом это должно быть прозрачно, он видит xml и ничего более.
И все же, классическим форматом для сервисов на сегодняшний день является XML. И тот же FaceBook, Amazon, все известные сервисы погоды или еще что-то.
Лично вы много видели сервисов работающих через json? пример если можно.
И все же, классическим форматом для сервисов на сегодняшний день является XML. И тот же FaceBook, Amazon, все известные сервисы погоды или еще что-то.
Лично вы много видели сервисов работающих через json? пример если можно.
Вы не о тех сервисах говорите. Смотрите, допустим у нас есть веб-приложение для управления личными контактами. У нас есть база контактов, у нас есть методы ( e.g. Contact.ChangeName(string name); ) которые делают определённые изменения в базе данных. Если интерфейс приложения делать так, чтобы действия пользователя не требовали перезагрузки страницы, то здесь и создаются веб-сервисы, к которым обращается скрипт в браузере. То есть, у нас есть веб-сервис contacts.asmx, у него есть WebMethod'ы, которые вызываются браузером и отдают информацию о результатах исполнения этого метода. Это и есть веб-сервисы в понимании ASP.NET.
Так вот, многим не нравится то, что ASP.NET Ajax генерирует слишком много скриптов и запросов к серверу. Хотя эта проблема решаема, многие предпочитают для этого использовать jQuery, о чём и писал автор статьи.
Так вот, многим не нравится то, что ASP.NET Ajax генерирует слишком много скриптов и запросов к серверу. Хотя эта проблема решаема, многие предпочитают для этого использовать jQuery, о чём и писал автор статьи.
не первый год работаю с веб-сервисами, странное у вас определение понятия «веб-сервис», независимо от терминологии asp.net.
"Веб-сервис поиска и заказов ЖД-билетов, его спецификация, подробное описание API" - так понятнее о чем речь?
"Веб-сервис поиска и заказов ЖД-билетов, его спецификация, подробное описание API" - так понятнее о чем речь?
Повторюсь, ваше понимание веб-сервисов("Поиск и заказ ЖД-билетов" и т.д.) и веб-сервис в asp.net - разные понятия. Здесь веб-сервис служит для того, чтобы обслужить нажатие какой-то одной кнопочки на веб-странице и отдать результат исполнения метода, присвоеного на событие, связанное с этой кнопочкой. Это не открытый API, спецификация в случае с одной кнопочкой или вообще элементами интерфейса в принципе. Да и не я придумывал это понятие, а Майкрософт :)
> Вы не о тех сервисах говорите.
> Здесь веб-сервис служит для того, чтобы обслужить нажатие какой-то одной кнопочки на веб-странице и отдать результат исполнения метода, присвоеного на событие, связанное с этой кнопочкой. Это не открытый API, спецификация в случае с одной кнопочкой или вообще элементами интерфейса в принципе. Да и не я придумывал это понятие, а Майкрософт :)
Упоительно! :D
Понятие Web-сервиса свелось к тому, что придумала Microsoft! :D
> Здесь веб-сервис служит для того, чтобы обслужить нажатие какой-то одной кнопочки на веб-странице и отдать результат исполнения метода, присвоеного на событие, связанное с этой кнопочкой. Это не открытый API, спецификация в случае с одной кнопочкой или вообще элементами интерфейса в принципе. Да и не я придумывал это понятие, а Майкрософт :)
Упоительно! :D
Понятие Web-сервиса свелось к тому, что придумала Microsoft! :D
и как написано автором выше "Вы писали НА .net веб-сервисы?", а не "сервисы в .net" (внутри и вообще — есть разница?)
Мне вообще приблизительно ваша точка зрения понятна, но не могли бы вы все же нормально развернуто ответить, чтобы небыло недопонимания, в том числе и у автора.
Если я правильно все понял, то в начале стоит большими буквами написать с какой версией .NET'а это работает. Кажется, версии 1 и 2 не умели отдавать ответ в json, если так и речь идет про более поздее версии, то почему бы не использовать оригинальное решение ASP.NET AJAX, а не jquery? Хотелось бы прочитать анализ, сравнение даных подходов.
Про ajax, web-службы и dotnet: существует гениальная библиотека jayrock.berlios.de, которая позволяет вызов web методы, написанные на второй версии .net, из клиентского js. Её плюс в том, что работает замечательно как в dotnet, так и в mono.
Про ajax, web-службы и dotnet: существует гениальная библиотека jayrock.berlios.de, которая позволяет вызов web методы, написанные на второй версии .net, из клиентского js. Её плюс в том, что работает замечательно как в dotnet, так и в mono.
Пользуюсь встроенными средствами .NET для этих целей. Мне не кажется, что экономия трафика у вас будет большой, но разводить код, который нужно поддерживать и отлаживать не есть гуд. Получение, например, описания элемента у меня реализуется следующим кодом:
MyService.GetDescription(id, descriptionLoad, descriptionError);
Где MyService - имя сервиса, id - код элемента для получения описания, и два метода, в случае успеха и в случае ошибки вызовутся соответственно.
Все, больше ничего в скрипте писать не нужно, зарегистрировать только веб сервис в ScriptManager ещё.
MyService.GetDescription(id, descriptionLoad, descriptionError);
Где MyService - имя сервиса, id - код элемента для получения описания, и два метода, в случае успеха и в случае ошибки вызовутся соответственно.
Все, больше ничего в скрипте писать не нужно, зарегистрировать только веб сервис в ScriptManager ещё.
Через ajax.net и я сервисы вызывал... но с jQuery все интереснее.
Я сейчас занялся написанием статьи, которая бы сравнила оба метода, закончу - выложу.
Потом обсудим результаты.
Я сейчас занялся написанием статьи, которая бы сравнила оба метода, закончу - выложу.
Потом обсудим результаты.
Договорились :)
написал, результаты для ajax.net хорошие, честно, не ожидал
http://habrahabr.ru/blog/net/44190.html
http://habrahabr.ru/blog/net/44190.html
А вообще какая разница на чем реализованы веб-сервисы, если они вызываются одинакого на клиенте. Есть урл, есть параметры, есть имя метода и все. Все это описывается в wsdl файле (языке описания сервисов). Разработчика на клиенте не должно интересовать на чем сделан веб-сервис, если это не критично (например, его волнует производительность методов на сервере). В идеале wsdl запрашивается, из него извлекается вся необходимая информация, далее делается запрос например по SOAP протоколу. И все. Именно так сделано у меня на клиенте, скорее всего напишу статью и будут рабочие примеры. Вот как сделано на клиенте (JS, WSDL SPEC 1.1 (W3C))
// Create soap client and load wsdl.
var oClient = new HSoap.Client("http://*******/wsdl/HAuth.wsdl");
// Construct service from wsdl.
var oAuth = oClient.ConstructService("HAuth");
// Work with service (sync call).
var oResult = oAuth.Login("MyName", "MyPassword");
oAuth.GetUserInfo(oResult.elmtAccuid);
// Work with service (async call).
oAuth.Login("MyName", "MyPassword", function(oResult) {}));
Для разработчика все прозрачно он вообще не заморачивается ни с http ни с параметрами ни с формированием xml, он просто вызывает методы в своем скрипте полностью сосредоточен на разработке своего приложения.
// Create soap client and load wsdl.
var oClient = new HSoap.Client("http://*******/wsdl/HAuth.wsdl");
// Construct service from wsdl.
var oAuth = oClient.ConstructService("HAuth");
// Work with service (sync call).
var oResult = oAuth.Login("MyName", "MyPassword");
oAuth.GetUserInfo(oResult.elmtAccuid);
// Work with service (async call).
oAuth.Login("MyName", "MyPassword", function(oResult) {}));
Для разработчика все прозрачно он вообще не заморачивается ни с http ни с параметрами ни с формированием xml, он просто вызывает методы в своем скрипте полностью сосредоточен на разработке своего приложения.
Что-то интересное в этом есть. Читал ранее об этом на http://encosia.com/2008/03/27/using-jque… (там же есть и про Page Methods).
Но вот стоит ли это использовать - для меня под вопросом.
Дело в том, что готовый JS фреймвёрк от MS довольно мощный и удобный.
Но вот стоит ли это использовать - для меня под вопросом.
Дело в том, что готовый JS фреймвёрк от MS довольно мощный и удобный.
Стоит, стоит. Есть такие случаи когда путь через jQuery - кратчайший.
Кроме того, этот пример платформонезависимый, а ajax.net - сами понимаете.
Кроме того, этот пример платформонезависимый, а ajax.net - сами понимаете.
Не знаю у кого еще спросить, скажите, а есть ли способ получить ID серверного контрола в .js файле? Хочется избавиться от JS кода в коде страницы, а так приходится писать что-то типа:
var tbxName = '<%= tbxName.ClientID %>';
var tbxName = '<%= tbxName.ClientID %>';
мне такой способ не известен и, я думаю, что его не существует из-за потенциального повторения одних и тех же html-элементов через пользовательские элементы управления. Рекомендую, там где это возможно, клиентскую часть писать в нативном html, а с сервером взаимодействовать через сервисы, так как написано в этой статье.
кстати не обязательно писать веб-сервисы (asmx-файлы), можно и в обычных страницах объявлять веб-методы (атрибут WebMethod)
С сервером то понятно. Просто не приятно когда в нативном html присутствует JavaScript.
кстати, могу предложить использовать для решения вашей проблемы jQuery. В нем можно гибко выбирать элементы управления по части идентификатора, вроде этого
$("input[@id*=slot]")
получим массив элементов input c id в котором есть подстрока "slot"
потенциально можно определить любой элемент созданный asp.net
$("input[@id*=slot]")
получим массив элементов input c id в котором есть подстрока "slot"
потенциально можно определить любой элемент созданный asp.net
Sign up to leave a comment.
Вызов веб-сервисов и веб-методов архитектуры.net