Comments 27
Статья получилась очень отрывчатая…
Ждем продолжения. knockoutjs интересен.
Как эту проблему обойти — навскидку не придумал.
Можно «завернуть» элемент jsfiddle.net/RJ7sr/1/
Именно эту функцию я использую для обновления модели в одном проекте
Т.к. у нас тут knockout.js то по хорошему нужно сделать биндинг к редактору (ko.bindingHandlers.redactor) — использовать будет удобней:
<textarea data-bind="redactor: content_value"></textarea>
Можно «завернуть» элемент jsfiddle.net/RJ7sr/1/
Вы правы, можно и так, но это дополнительный объект, который может быть оправдан если полей будет несколько. Добавил в статью.
нужно сделать биндинг к редактору
Да, так можно сделать, но только в том случае, если известный
textarea будет контейнером редактора, а если область для редактирования создаётся динамически, то всё равно придётся писать плагин или править шаблон в исходниках редактора.
Всем нравится knockout, но я так и не нашел примеров организации кода, и особенно таких частей, как синхронизация с REST-сервером, чтобы не изобретать велосипед и стыдно не было. Может кто что подскажет?
P.S. курс от John Papa видел.
P.S. курс от John Papa видел.
А нокаут и не предоставляет никаких методов для работы с сервером, разве что работа с json, просто задача библиотеки другая. И как мне кажется, не собирается. В одном проекте у меня вобще написан отдельный модуль для работы с запросами к серверу, получением данных (+обёртка в наблюдаемые) и кэшированием. Но так же можно использовать knockback, хотя это уже некоторое нагромождение.
Создавать двустороннюю наблюдаемую (observable) привязку интерфейса и модели, т.е. в реальном времени будет обновляться интерфейс при изменении модели, а модель при изменении в интерфейсе (рабочий пример при вводе текста в формах). Тут есть один нюанс, в input полях обновление модели произойдёт только при событии onblur (убрать фокус с элемента), данную ситуацию можно исправить, подписавшись на событие input, соответственно вручную обновлять модель. Пример на jsfiddle.
можно сделать при помощи установки valueUpdate как «afterkeydown»
+ не думаю, что это хорошо, если view model занимается обработкой событий инпутов и тд (т.к. жестко привязывается ко вьюхе), для этого есть механизмы экстендеров, биндинг хандлеров.
Чтобы сделать качественный интерфейс, придётся реагировать не только на обновления модели, но и на другие события из DOM. В данный момент мне кажется, что привязка обработчиков через биндинг — это нормально, возможно я не прав или не имею достаточного опыта, можете привести пример вашей реализации?
А чем это плохо? Где тогда лучше обрабатывать?
Получается спагетти-код. Например, в биндинг хандлерах.
Допустим, есть какой-нибудь компонент или jquery-плагин, его можно красиво обернуть в биндинг хандлер и декларативно описывать вьюхи таким образом:
Во вью-модели будет только логика и данные, в биндинг-хандлере будет инициалиция компонета/плагина и обработка изменений вьюмодели.
Допустим, есть какой-нибудь компонент или jquery-плагин, его можно красиво обернуть в биндинг хандлер и декларативно описывать вьюхи таким образом:
<textarea class="tinymce" data-bind="tinymce: description, tinmymceoptions: { fontsize: 14 }}"></textarea>Во вью-модели будет только логика и данные, в биндинг-хандлере будет инициалиция компонета/плагина и обработка изменений вьюмодели.
Спасибо!
У любой медали 2 стороны. То что Вы описали, действительно хорошо, но только тогда, когда необходимо повторное использование и когда кода много настолько, что можно получить спагетти. В противном случае, можно и не вводить к вью и вью модели еще и биндинг хандлер, чтобы не усложнять (по поводу связанности вью и вью модели — вряд ли это так страшно).
У любой медали 2 стороны. То что Вы описали, действительно хорошо, но только тогда, когда необходимо повторное использование и когда кода много настолько, что можно получить спагетти. В противном случае, можно и не вводить к вью и вью модели еще и биндинг хандлер, чтобы не усложнять (по поводу связанности вью и вью модели — вряд ли это так страшно).
Можно, но событие input будет срабатывать даже при вставке текста через Ctrl + V и через обычный drag-n-drop.
Автор, почему в первом примере для привязки используется html если поля во viewModel обычный текст:
к то муже после привязки они еще магическим образом превращаются в value:
хотя там самое место быть бы text.
Мне кажется Вы вводите новичков в заблуждение касаемо использования bindings имеющихся по умолчанию в knockout. Либо поясните пожалуйста как так получается.
<span data-bind=”html: attribute1”>Hello</span>
к то муже после привязки они еще магическим образом превращаются в value:
<span data-bind=”value: attribute1”>Hello</span>
хотя там самое место быть бы text.
Мне кажется Вы вводите новичков в заблуждение касаемо использования bindings имеющихся по умолчанию в knockout. Либо поясните пожалуйста как так получается.
Тут есть один нюанс, в input полях обновление модели произойдёт только при событии onblur (убрать фокус с элемента)…
Что бы было в «реальном времени» разработчики советуют использовать valueUpdate, а в него можно передать: keyup, keypress, afterkeydown… Лучшем выбором будет afterkeydown.
документация
В комментариях выше мы уже разобрали этот момент.
Интересно, спасибо :) В будущих статьях хотелось бы почитать как вы делите нокаут-код на модули (чтобы на разных страницах использовать различные их комбинации). И ещё, возможно, вы сталкивались и решили как-то проблему пред-заполнения моделей из отрендеренного на сервере html.
Что вы имеете в виду под модульностью? Возможность использовать несколько моделей на одной странице, использование разделяемой модели (когда одна модель и несколько шаблонов)? Или просто приведите пару примеров.
С задачей заполнения моделей из уже готового html не сталкивался. И насколько я знаю, декларативная модель нокаута это и не собирается поддерживать. Полагаю, что лучше получить данные с сервера и поместить их в DOM уже на клиенте. Можно пример, в каких условиях вам это понадобилось?
С задачей заполнения моделей из уже готового html не сталкивался. И насколько я знаю, декларативная модель нокаута это и не собирается поддерживать. Полагаю, что лучше получить данные с сервера и поместить их в DOM уже на клиенте. Можно пример, в каких условиях вам это понадобилось?
И первое и второе, видимо. Допустим есть у вас на отдельной странице фотки пользователя. И хочется часть фоток показать на странице профиля. Получается, что у модели фоток будет несколько шаблонов (разные для разных страниц). И на странице профиля будет кроме модели фоток ещё своя модель.
Заполнение моделей из html нужно для поисковой оптимизации. Из за этого приходится рендерить страницы на сервере. И сейчас просто встраиваем в страницу json для нокаута. Но это увеличивает размер страниц примерно на треть.
Заполнение моделей из html нужно для поисковой оптимизации. Из за этого приходится рендерить страницы на сервере. И сейчас просто встраиваем в страницу json для нокаута. Но это увеличивает размер страниц примерно на треть.
Нокаут очень хорош для одностраничных приложений (можно иметь одну большую разделяемую модель с данными — этакое хранилище и несколько маленьких для специфических шаблонов), но если реальных страниц несколько, можно выносить используемые модели данных в отдельные файлы. Тут еще зависит от конкретного случая, путей решения может быть несколько. Иногда лучше расширять модель, а иногда иметь несколько не связанных.
А поисковики же научились исполнять js и индексировать ajax запросы, есть даже официальные туториалы от яндекса и гугла и много статей на хабре. Может я не знаю каких-то особенностей, но если вам это не подходит, то можно для поисковиков отдавать статическую страницу, а для браузеров нормальную. Или после загрузки страницы запрашивать json (или парсить страницу) и заменять статические данные — шаблонами, т.е. рендерить заново, но только уже нокаутом.
А поисковики же научились исполнять js и индексировать ajax запросы, есть даже официальные туториалы от яндекса и гугла и много статей на хабре. Может я не знаю каких-то особенностей, но если вам это не подходит, то можно для поисковиков отдавать статическую страницу, а для браузеров нормальную. Или после загрузки страницы запрашивать json (или парсить страницу) и заменять статические данные — шаблонами, т.е. рендерить заново, но только уже нокаутом.
Вопрос. Очень заинтересовался этой библиотекой. К сожалению углублённое изучение и использование просто умирает. Посоветуйте, пожалуйста, что-нибудь из гридов для использования с этой библиотекой. Перерыл весь гугль — старые посты с невнятными, отрывочными и неполными решениями и «рекомендациями с коленки». Как в анекдоте — берём, а потом «долго пилим напильником»
На данный момент нашёл:
— datatables — проблема связки не решена, есть глюки, которые, возможно, решатся в будущем релизе.
— «нативная» koGrid — отличный грид, но более полугода, кажется, не обновлялся и… глюк за глюком… Мне так и не удалось сделать элементарный autosize viewport'a. Надо курить css, что в отсутствии документации более чем времязатратно.
— kendo — вроде там всё красиво, но платить сотни долларов для своих бесплатных, но полезных людям проектов, я не готов. Смысл?
Если можете посоветовать что-то, что просто сочетается с knockout.js — я был бы очень благодарен ибо сама библиотека просто великолепна. Переписал один из своих проектов просто для изучения — код уменьшился втрое и стал более понятен и нагляден.
Да и вообще, не только гриды. Любые библиотеки, которые бесплатны но легко сочетаются с konockout были бы интересны. Понятно что всё это подбирается под задачу, но всегда лучше знать что что-то есть, чем как я — просто убить неделю на лазание по гуглям. Просто что-то из используемого или знакомого — специально искать не надо.
Жалко своего времени. Я могу, конечно, допилить koGrid до нужного уровня, но может быть есть что-то уже готовое и бесплатное?
Буду «настоятельно» благодарен за советы.
На данный момент нашёл:
— datatables — проблема связки не решена, есть глюки, которые, возможно, решатся в будущем релизе.
— «нативная» koGrid — отличный грид, но более полугода, кажется, не обновлялся и… глюк за глюком… Мне так и не удалось сделать элементарный autosize viewport'a. Надо курить css, что в отсутствии документации более чем времязатратно.
— kendo — вроде там всё красиво, но платить сотни долларов для своих бесплатных, но полезных людям проектов, я не готов. Смысл?
Если можете посоветовать что-то, что просто сочетается с knockout.js — я был бы очень благодарен ибо сама библиотека просто великолепна. Переписал один из своих проектов просто для изучения — код уменьшился втрое и стал более понятен и нагляден.
Да и вообще, не только гриды. Любые библиотеки, которые бесплатны но легко сочетаются с konockout были бы интересны. Понятно что всё это подбирается под задачу, но всегда лучше знать что что-то есть, чем как я — просто убить неделю на лазание по гуглям. Просто что-то из используемого или знакомого — специально искать не надо.
Жалко своего времени. Я могу, конечно, допилить koGrid до нужного уровня, но может быть есть что-то уже готовое и бесплатное?
Буду «настоятельно» благодарен за советы.
Готовых хороших гридов я не искал, реализовываю всё сам, под конкретную задачу. Мне кажется, что если хотите готовых контролов, лучше посмотреть на ангуляр. Но согласен с вами, что под нокаут мало качественных готовых контролов, приходится писать всё самому.
Спасибо, посмотрел. Подход knockout мне понравился больше, но тоже, очевидно, мощная штука. Иногда у меня опускаются руки :) Вокруг такое обилие интереснейших и удобнейших технологий, библиотек, паттернов, что иногда просто опускаются руки. За всем не уследишь, а так жаль. Столько вокруг интересного, где бы купить пару сотен лет жизни? :)
Если что-то придёт в голову в сторону knockout — я буду очень благодарен. Я знаю где и как её применить в большом проекте, что почти сразу облегчит жизнь массе людей.
К сожалению гриды это как раз то, что лень писать самому. Даже не лень, а жалко своего времени на очередной велосипед. Буду пилить kogrid. В работу такое не пустишь, а для одного из моих проектиков поиска по онлайн магазинам настольных игр — то что надо.
Спасибо за ответ
Если что-то придёт в голову в сторону knockout — я буду очень благодарен. Я знаю где и как её применить в большом проекте, что почти сразу облегчит жизнь массе людей.
К сожалению гриды это как раз то, что лень писать самому. Даже не лень, а жалко своего времени на очередной велосипед. Буду пилить kogrid. В работу такое не пустишь, а для одного из моих проектиков поиска по онлайн магазинам настольных игр — то что надо.
Спасибо за ответ
Sign up to leave a comment.
Применение, советы и особенности knockout.js