Comments 48
Мы подобную штуку, но сугубо для текстовых полей, реализовали использую redis для хранения и readctor для инлайнового редактирования, вышло всё в один темлпйт тег и одну вьюху =)
Не подскажете как такой WYSIWYG без боли заиспользовать для полей обычных форм и желательно в каком-то виде использовать ajax загрузку картинок?
Редактор здесь imperavi.com/redactor/ Работает на Jquery, подключается без проблем.
Редактирование включается сразу для всех полей на странице?
Валидация полей в какой момент происходит и как сообщается об ошибках?
Валидация полей в какой момент происходит и как сообщается об ошибках?
Зачем вы каверзные вопросы задаете? :) Я думаю всегда можно ( забыл) что-то вроде onAjaxFailure обрабатывать для всех запросов.
Просто у меня к методам программирования форм (и вообще UI) столько претензий, что если я их выскажу, меня забанят. Формы конкретно в Django устарели лет 5 назад. Понятно, что в Django любой механизм можно заменить своим, но я не вижу и сторонних разработок хорошего качества. Тема редактирования без перезагрузки страницы вообще плохо раскрыта. Однажды я написал статью про вложенные формы (форма содержит особое поле, которое само является формой или формсетом), так ее обосрали с ног до головы. Вот и остается ходить, да вопросы задавать :-)
А как же twitter-bootstrap + обвес на js?
Формы вообще, как мне кажется, у старели не в Django, а в HTML вообще. Поэтому все сторонние разработки не универсальны либо кривы, потому как решают конкретные задачи конкретными способами. В связи с чем конкретными приемами удается решать те или иные задачи. Мне от тега form в текущем одностраничном приложении вообще пришлось отказаться. Использую кошмарные конструкции типа
а потом сериализую object.data() при каждом клике
И таки да, начинаются жестокие костыли в зависимости от того на какой объект навешивается такое поведение. Для чекбоксов одно, для drop-down другое, для radio третье
ЗЫЖ Дайте ссылку на вашу статью, есть желание обосрать что-нибудь с утра пораньше
Формы вообще, как мне кажется, у старели не в Django, а в HTML вообще. Поэтому все сторонние разработки не универсальны либо кривы, потому как решают конкретные задачи конкретными способами. В связи с чем конкретными приемами удается решать те или иные задачи. Мне от тега form в текущем одностраничном приложении вообще пришлось отказаться. Использую кошмарные конструкции типа
parameters = {:report_id => @report.id, :object => 'testdrive', :section => 'engine', :place => param}
.control-group.object{:data => parameters}
а потом сериализую object.data() при каждом клике
@store_point = (element) ->
data = element.data()
if data.id
$.ajax
url: "/points/#{data.id}.json"
type: 'PUT'
data: {point: data}
else
$.ajax
url: '/points.json'
type: 'POST'
data: {point: data}
И таки да, начинаются жестокие костыли в зависимости от того на какой объект навешивается такое поведение. Для чекбоксов одно, для drop-down другое, для radio третье
ЗЫЖ Дайте ссылку на вашу статью, есть желание обосрать что-нибудь с утра пораньше
Редактирование включается для выбранного поля (в нашем случае по клику). Значение отправляется на сервер, там валидируется и возвращает результат.
… и если результатом будет ошибка, то…?
Но ведь часто бывает так, что поле может быть валидным само по себе, но невалидным в контексте самой формы. Самый простой пример — пароль и его подтверждение различаются, хотя оба поля сами по себе удовлетворяют условиям сложности
Я бы пароль редактировать таким способом не стал бы. Лучше вывести форму для ввода старого пароля и нового.
Это был лишь пример того, когда корректное значение одного поля может вызывать ошибку валидации формы в целом. Если не нравятся пароли и подтверждения, пожалуйста, давайте попробуем по-другому: пользователь должен задать некий временной интервал. В форме есть два поля: для ввода начала и конца этого интервала. Каждое из этих полей формы может быть заполнено верно (даты типа 30 февраля не пройдут), а как быть с проверкой, например, что
end_date больше start_date? Или что длина интервала не менее 2 месяцев?Как вариант описать свой адаптер для обработки двух полей, а не посылать их на сервер по отдельности. И добавить дополнительную валидацию на JavaScript в шаблоне для большей уверенности.
Это уже размазывание логики получается. И нарушение DRY =)
Подловили))
Подтверждение пароля не редактируется через inplace. Вот и все. Хватит придумывать нелетающих бабочек :)
Вы, дружище, кажется, через слово читаете :-)
Либо я как-то уж совсем невнятно мысли формулирую. Вроде бы основной посыл был про то, что форму нужно валидировать целиком, а не каждое поле в отдельности. А пароли, или диапазоны — не суть важно, это всё частности.
Либо я как-то уж совсем невнятно мысли формулирую. Вроде бы основной посыл был про то, что форму нужно валидировать целиком, а не каждое поле в отдельности. А пароли, или диапазоны — не суть важно, это всё частности.
Да нет же, просто неудобно забивать шурупы микроскопом :-)
Inline edit — update в существующую запись — можно производить валидацию данных, а не формы. Валидация подскажет пользователю какие данные не согласованы.
Inline edit — update в существующую запись — можно производить валидацию данных, а не формы. Валидация подскажет пользователю какие данные не согласованы.
Я не понимаю, о чём Вы, Простите. О какой валидации данных речь?
Перед UPDATE можно проверить, соответствуют ли данные логике.
А форма не этим занимается?
Это уже размазывание логики получается. И нарушение DRY =)
Я правильно понимаю, что Вы предлагаете сделать что-то типа
и считаете, что это не размазывание логики и не нарушение DRY?
if form.is_valid():
if form.cleaned_data['start_date'] >= form.cleaned_data['end_date']:
message.error('Неверный интервал')
else:
form.save()
и считаете, что это не размазывание логики и не нарушение DRY?
Я считаю, что форма должна передавать сырые данные серверу. Форма занимается приемом данных от пользователя. Форма не должна заниматься обработкой ошибок. Этим должен заниматься сервер приложений.
Что ж, у Вас есть право на личное мнение :-) Но оно не совпадает со мнением разработчиков джанги, которые считают, что
вполне себе задачи форм (в самом начале, пп 2 и 4).
Я тоже считаю, что форма должна валидировать данные. Кстати, это не обязательно могут быть данные, пришедшие с HTTP, а что угодно, хотя бы пользовательский ввод:
и кстати, разве форма не является частью сервера приложений?
- Check submitted data against a set of validation rules.
- Convert submitted form data to the relevant Python data types.
вполне себе задачи форм (в самом начале, пп 2 и 4).
Я тоже считаю, что форма должна валидировать данные. Кстати, это не обязательно могут быть данные, пришедшие с HTTP, а что угодно, хотя бы пользовательский ввод:
data = {
'name': raw_input("Enter your name: "),
'age': raw_input("Enter your age: ")
}
form = Form(data)
if not form.is_valid():
print "Something goes wrong"
и кстати, разве форма не является частью сервера приложений?
Нет, форма не является частью сервера приложений, т.к. исполняется на клиентской стороне.
| Check submitted data against a set of validation rules.
Т.е. submit уже состоялся, значит данные уже на сервере.
| Convert submitted form data to the relevant Python data types.
Т.е. submit уже состоялся, значит данные уже на сервере.
В приведенном вами примере, Form (Класс?) не имеет ничего общего с HTML form. В HTML from отсутствуют механизмы валидации данных.
| Check submitted data against a set of validation rules.
Т.е. submit уже состоялся, значит данные уже на сервере.
| Convert submitted form data to the relevant Python data types.
Т.е. submit уже состоялся, значит данные уже на сервере.
В приведенном вами примере, Form (Класс?) не имеет ничего общего с HTML form. В HTML from отсутствуют механизмы валидации данных.
Кажется, разобрались. Мы говорим о разных вещах.
Для меня, как и, надеюсь, для большинства джанго-разработчиков, форма — это то, с чем работаем мы на сервер-сайде. То есть часть джанги. А не какой-то там html-код, за который должны отвечать верстальщики :-)
Для меня, как и, надеюсь, для большинства джанго-разработчиков, форма — это то, с чем работаем мы на сервер-сайде. То есть часть джанги. А не какой-то там html-код, за который должны отвечать верстальщики :-)
Зато я теперь знаю как утроен родственный разум. Я rails-разработчик.
А, ясно. На огонёк зашли, или так, потроллить? :-)
Упоси святой скотч, никакого троллинга! Я знаю ряд django-разработчиков и уважаю их. Тем более, что теперь я умею их готовить :) Огонек в том, что тема динамических форм полностью не раскрыта, и если кто-то изобретает этот велосипед на костыльном ходу, то не воспользоваться опытом было бы непростительно. Лучше даже сразу застрелиться!
Валидация помогает с датами.
Пример с паролем уникален тем, что необходимо одновеременно отправлять.
Да и плохой тон уже спрашивать пароль повторно.
Пример с паролем уникален тем, что необходимо одновеременно отправлять.
Да и плохой тон уже спрашивать пароль повторно.
Валидация помогает с датами.
Что, простите?
Вы привели пример с датами. Валидатор не может работать с датами?
Вы уточните, пожалуйста, какой валидатор?
errors = []
if end_date > start_date
errors.push 'end_date больше start_date'
else
update_fields
end
примитивный валидатор
if end_date > start_date
errors.push 'end_date больше start_date'
else
update_fields
end
примитивный валидатор
Именно этим форма и занимается.
Форма не должна этим заниматься. Т.к. тем же примитивным фаербагом можно с формой сделать все что угодно и она отвалидированная улетит на сервер. Тогда нужно валидировать данные уже на сервере. Зачем делать двойную работу в двух местах? Еще и тестировать придется разными методами.
Именно что должна.
Но на клиентскую валидацию действительно полагаться нельзя, поэтому она (валидация) должна происходить на сервере. А JS, который всего лишь упрощает жизнь пользователю, должен всего лишь гонять от клиента серверу введённые данные и обратно, от сервера клиенту, решение сервера о том, верно ли всё заполнено.
Но как бы то ни было, задача валидации лежит целиком на машинерии формы.
P.S. На самом деле, в моделях тоже есть валидация, но это другой вопрос.
Но на клиентскую валидацию действительно полагаться нельзя, поэтому она (валидация) должна происходить на сервере. А JS, который всего лишь упрощает жизнь пользователю, должен всего лишь гонять от клиента серверу введённые данные и обратно, от сервера клиенту, решение сервера о том, верно ли всё заполнено.
Но как бы то ни было, задача валидации лежит целиком на машинерии формы.
P.S. На самом деле, в моделях тоже есть валидация, но это другой вопрос.
Делал подобный функционал на плагине для jQuery jEditable. Он достаточно простой: для необходимых элементов указываются адрес, куда должен слаться POST запрос. При клике на такой элемент он заменяется на поле редактирования (возможен вариант использовать TinyMCE) после чего шлется обычный POST, куда в качестве параметров приходит id и value. Результат этого запроса, если он не пустой, будет новым значением для элемента.
Подключается скрипт:
Добавляется возможность редактирования к необходимым полям:
В шаблоне делаются две вещи: назначается класс, соответствующий редактируемому полю и создается id по следующей схеме НАЗВАНИЕ_КЛАССА:ID_ОБЪЕКТА.СВОЙСТВО (этот способ ни на что не претендует, просто он был удобен лично мне). Новое значение из поля редактирования придет в POST запрос в свойстве «value»
Ниже пример обработчика для Flask, для Django суть будет та же:
Но достоинство такого метода в том, что можно что угодно использовать, хоть PHP.
Подключается скрипт:
<script src="/static/js/jquery.jeditable.js"></script>Добавляется возможность редактирования к необходимым полям:
$(document).ready(function() {
$(".editable").editable("/ajax/update");
$(".editable-area").editable("/ajax/update", {
type : "mce",
cancel : "Отмена",
submit : "Сохранить",
});
});
В шаблоне делаются две вещи: назначается класс, соответствующий редактируемому полю и создается id по следующей схеме НАЗВАНИЕ_КЛАССА:ID_ОБЪЕКТА.СВОЙСТВО (этот способ ни на что не претендует, просто он был удобен лично мне). Новое значение из поля редактирования придет в POST запрос в свойстве «value»
<h1 class="editable" id="post:{{ post.id }}.title">{{ post.title }}</h1>
Ниже пример обработчика для Flask, для Django суть будет та же:
@app.route("/ajax/update", methods=['POST'])
@authDB.requires_auth
def ajax_update():
# object:id.attribute -> object_name object_id field
parts = request.form['id'].split(".")
id_parts = parts[0].split(":")
object_name = id_parts[0]
object_id = id_parts[1]
field = parts[1]
if object_name == "post":
post = Post.objects.get(id=object_id)
post[field] = request.form['value']
post.save()
return request.form['value']
if object_name == "...":
...
return request.form['value']
return ""
Но достоинство такого метода в том, что можно что угодно использовать, хоть PHP.
А ошибки как обрабатывать?
На сервере — никто не ограничивает в способах валидации. На клиенте — тоже, можно обрабатывать onSubmit stackoverflow.com/questions/2425456/validate-jeditable-field
Что за сайт? Дайте потыкать в живую, заодно и резюме, судя по всему, размещу )
Потыкать в живую можно здесь http://resumeo.me/
Sign up to leave a comment.
Inline редактирование в Django