Comments 40
Очень интересно. Спасибо
Идея сама по себе более чем здравая. И, если реализация не будет приводить к таким же проблемам, как behavior'ы и связывание с XML в старых версиях IE (не знаю, поддерживаются ли эти технологии в новых — после проблем, с которыми столкнулся несколько лет назад, желание экспериментировать с ними пропало), то это может быть весьма востребовано.
UFO just landed and posted this here
UFO just landed and posted this here
Идея весьма ценная
Связывание — это конечно хорошо, но только на достаточно толстом канале от сервера до пользователя, а если каналчик плохенький GPRS или ещё лучше Dial-Up, то по производительности — это будет издевательством над конечным потребителем.
А как связь между пропускной способностью канала и программированием клиента? Вы имеете в виду что размер файла библиотеки будет издевательством? Он будет не сильно больше относительно стандартного jQuery.
Да дело не в размере jQuery, хотя он тоже важен.
Дело в передаваемых данных, которые будут постоянно гоняться для поддержания синхронизации, точнее для опроса клиентом сервера.
Дело в передаваемых данных, которые будут постоянно гоняться для поддержания синхронизации, точнее для опроса клиентом сервера.
Сервер тут ни при чем. Связывание происходит на клиенте, между данными клиента.
Ага… а данные откуда берутся по вашему?
К тому же я, если честно, не вижу смысла просто гонять какие-то данные просто по странице, внутри дума и между js-объектами, без сохранения их на сервере.
К тому же я, если честно, не вижу смысла просто гонять какие-то данные просто по странице, внутри дума и между js-объектами, без сохранения их на сервере.
Внимательно перечитайте статью. Если ваша точка зрения не изменится можете смело начинать искать статью типа «Для чего нужен JQuery | Принципы работы JQuery | Задачи решаемые с помощью JQuery»
Я достаточно чётко себе представляю для чего нужна данная библиотека (иначе не юзал бы её), да и статью перечитал уже несколько раз.
Скорее всего я просто гоняюсь за призраками прошлого. Когда идёт борьба за каждый переданный с/на клиента килобайт. Когда неосторожное движение скриптом может загнать браузер в стопур из-за того, что он полностью интерпритирует js, а не делает предкомпиляцию… Когда особенность работа js в IE зависит не только от его версии… но и от того как он попал в систему, как это было с IE7 (шел в комплекте с ОС или был поставлен в качестве обновления IE 6).
Скорее всего я просто гоняюсь за призраками прошлого. Когда идёт борьба за каждый переданный с/на клиента килобайт. Когда неосторожное движение скриптом может загнать браузер в стопур из-за того, что он полностью интерпритирует js, а не делает предкомпиляцию… Когда особенность работа js в IE зависит не только от его версии… но и от того как он попал в систему, как это было с IE7 (шел в комплекте с ОС или был поставлен в качестве обновления IE 6).
Тут никуда ничего не передаётся! Предложенные пока что плагины связывают один объект с другим. Соответственно если у вас будет связано 200 объектов на странице вам не придётся у каждого или посредством выборки изменять что либо в объекте все манипуляции будут произведены автоматичесски
Автоматически — это только значит, что это уже написано и вам не нужно это реализовывать самому, а всё равно это будет выполняться и проблемы с браузерами решать вам и выполнять при этом финты ушами тоже вам.
Могу привести пример из жизни:
Был у нас заказчик. Попросил он работу с данными в гриде, а так же попросил оставить настройку в конфиге приложения — сколько можно максимально выводить строк в грид. Сказано — сделано… ничего сложного в этом нет.
Мы конечно дали рекомендацию, что максимальное значение не стоит задавать больше двухсот-трёхсот строчек.
Заказчик же (точнее бизнес — заказчик) решил что 200-300 строчек — это не круто, давайте-ка будем выводить несколько тысяч, хоть в этом и не было практической пользы. В хроме и лисе всё продолжало нормально работать при групповых операциях (максимум четыре — пять секунд на типовом PC). А вот IE 6-7 выполнял теже скрипты за 16 минут (8 — около 10 минут). Технический персонал со стороны заказчика понимал, что такое требование — это бред, но бизнес упёрся всё тут.
Мы неделю потратили на различные эксперименты на взаимодействия сервера и браузера, чтобы разделить функционал так чтобы вывести работу на оптилные пять секунд.
Возможно, пессимист и вижу всегда самое плохое и только проблемы, которые возможны теоретически… но так меня научила жизнь.
Могу привести пример из жизни:
Был у нас заказчик. Попросил он работу с данными в гриде, а так же попросил оставить настройку в конфиге приложения — сколько можно максимально выводить строк в грид. Сказано — сделано… ничего сложного в этом нет.
Мы конечно дали рекомендацию, что максимальное значение не стоит задавать больше двухсот-трёхсот строчек.
Заказчик же (точнее бизнес — заказчик) решил что 200-300 строчек — это не круто, давайте-ка будем выводить несколько тысяч, хоть в этом и не было практической пользы. В хроме и лисе всё продолжало нормально работать при групповых операциях (максимум четыре — пять секунд на типовом PC). А вот IE 6-7 выполнял теже скрипты за 16 минут (8 — около 10 минут). Технический персонал со стороны заказчика понимал, что такое требование — это бред, но бизнес упёрся всё тут.
Мы неделю потратили на различные эксперименты на взаимодействия сервера и браузера, чтобы разделить функционал так чтобы вывести работу на оптилные пять секунд.
Возможно, пессимист и вижу всегда самое плохое и только проблемы, которые возможны теоретически… но так меня научила жизнь.
UFO just landed and posted this here
UFO just landed and posted this here
А связывание будет 2-х сторонним?
Например если мы напишем:
var person = { Name: 'Вася'};
$('name').linkTo(«val», person, «Name»);
person.Name = 'Петя';
что выдаст
alert($('name').val());
?
Например если мы напишем:
var person = { Name: 'Вася'};
$('name').linkTo(«val», person, «Name»);
person.Name = 'Петя';
что выдаст
alert($('name').val());
?
На первый взгляд выглядит круто. Надо пробовать
разработчики asp.net подглядели DataBinding у команды WPF и решили его как-то эмулировать? ;)
И правильно сделали — решение ведь отличное, сейчас очень не хватает полноценного MVVM на javascript.
у разработчиков asp.net уже давно есть биндинг в библиотеке asp.net ajax
Биндинги уже очень-очень давно в фреймворке cocoa bindings (угадайте почему он так называется :)). Они появились задолго до появления WPF и asp.net.
Интересная идея.
Можно будет привязывать поля формы к атрибутам объектов, которые в последствии, обернув в JSON, можно передать на сервер, где так же развернуть из json'а в объект уже на серверном языке.
Даже знаю уже где это можно применить у себя в проекте! :) Прям вот возьму и попробую.
Можно будет привязывать поля формы к атрибутам объектов, которые в последствии, обернув в JSON, можно передать на сервер, где так же развернуть из json'а в объект уже на серверном языке.
Даже знаю уже где это можно применить у себя в проекте! :) Прям вот возьму и попробую.
А зачем нудно связывание, есть практический пример? Я что-то не представляю, не проще ли например в момент нажатия кнопки сабмит читать значения полей и делать с ними что-нибудь, а не делать лишнюю работу? Или кто-то начитался дурных идей Мартина Фаулера? Или они хотят и яваскрипт под свою неуклюжую идеологию ASP подогнать?
И зачем нужны attrChange и arrayChange?
И зачем нужны attrChange и arrayChange?
Все бы хорошо, но вот жесткая привязка к дому делает плагин неполноценным.
Sign up to leave a comment.
Предложение по добавлению связывания данных