@int22h10 ноя 2012 в 16:04

Inline редактирование в Django

4 мин

19K

Django * Веб-разработка *

+23

Комментарии 48

@nvbn 10 ноя 2012 в 21:38

Мы подобную штуку, но сугубо для текстовых полей, реализовали использую redis для хранения и readctor для инлайнового редактирования, вышло всё в один темлпйт тег и одну вьюху =)

@gasya 10 ноя 2012 в 21:57

Не подскажете как такой WYSIWYG без боли заиспользовать для полей обычных форм и желательно в каком-то виде использовать ajax загрузку картинок?

@int22h 11 ноя 2012 в 01:32

Редактор здесь imperavi.com/redactor/ Работает на Jquery, подключается без проблем.

@max_rip 12 ноя 2012 в 00:08

Только он теперь платный стал (

@StopDesign 11 ноя 2012 в 03:00

Редактирование включается сразу для всех полей на странице?
Валидация полей в какой момент происходит и как сообщается об ошибках?

@Renius 11 ноя 2012 в 04:01

Зачем вы каверзные вопросы задаете? :) Я думаю всегда можно ( забыл) что-то вроде onAjaxFailure обрабатывать для всех запросов.

@StopDesign 11 ноя 2012 в 05:10

Просто у меня к методам программирования форм (и вообще UI) столько претензий, что если я их выскажу, меня забанят. Формы конкретно в Django устарели лет 5 назад. Понятно, что в Django любой механизм можно заменить своим, но я не вижу и сторонних разработок хорошего качества. Тема редактирования без перезагрузки страницы вообще плохо раскрыта. Однажды я написал статью про вложенные формы (форма содержит особое поле, которое само является формой или формсетом), так ее обосрали с ног до головы. Вот и остается ходить, да вопросы задавать :-)

@Renius 12 ноя 2012 в 04:53

А как же twitter-bootstrap + обвес на js?
Формы вообще, как мне кажется, у старели не в 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 третье

ЗЫЖ Дайте ссылку на вашу статью, есть желание обосрать что-нибудь с утра пораньше

@int22h 11 ноя 2012 в 07:18

Редактирование включается для выбранного поля (в нашем случае по клику). Значение отправляется на сервер, там валидируется и возвращает результат.

@Renius 12 ноя 2012 в 04:42

… и если результатом будет ошибка, то…?

@int22h 12 ноя 2012 в 06:53

То будет выведено сообщение об ошибке…

@Renius 13 ноя 2012 в 05:06

… выведено на принтер?

@marazmiki 12 ноя 2012 в 05:08

Но ведь часто бывает так, что поле может быть валидным само по себе, но невалидным в контексте самой формы. Самый простой пример — пароль и его подтверждение различаются, хотя оба поля сами по себе удовлетворяют условиям сложности

@int22h 12 ноя 2012 в 06:55

Я бы пароль редактировать таким способом не стал бы. Лучше вывести форму для ввода старого пароля и нового.

@marazmiki 12 ноя 2012 в 07:16

Это был лишь пример того, когда корректное значение одного поля может вызывать ошибку валидации формы в целом. Если не нравятся пароли и подтверждения, пожалуйста, давайте попробуем по-другому: пользователь должен задать некий временной интервал. В форме есть два поля: для ввода начала и конца этого интервала. Каждое из этих полей формы может быть заполнено верно (даты типа 30 февраля не пройдут), а как быть с проверкой, например, что end_date больше start_date? Или что длина интервала не менее 2 месяцев?

@int22h 12 ноя 2012 в 07:43

Как вариант описать свой адаптер для обработки двух полей, а не посылать их на сервер по отдельности. И добавить дополнительную валидацию на JavaScript в шаблоне для большей уверенности.

@marazmiki 12 ноя 2012 в 07:50

Это уже размазывание логики получается. И нарушение DRY =)

@int22h 12 ноя 2012 в 07:53

Подловили))

@Renius 12 ноя 2012 в 09:32

Подтверждение пароля не редактируется через inplace. Вот и все. Хватит придумывать нелетающих бабочек :)

@marazmiki 12 ноя 2012 в 09:35

Вы, дружище, кажется, через слово читаете :-)
Либо я как-то уж совсем невнятно мысли формулирую. Вроде бы основной посыл был про то, что форму нужно валидировать целиком, а не каждое поле в отдельности. А пароли, или диапазоны — не суть важно, это всё частности.

@Renius 12 ноя 2012 в 09:41

Да нет же, просто неудобно забивать шурупы микроскопом :-)
Inline edit — update в существующую запись — можно производить валидацию данных, а не формы. Валидация подскажет пользователю какие данные не согласованы.

@marazmiki 12 ноя 2012 в 09:48

Я не понимаю, о чём Вы, Простите. О какой валидации данных речь?

@Renius 12 ноя 2012 в 09:53

Перед UPDATE можно проверить, соответствуют ли данные логике.

@marazmiki 12 ноя 2012 в 09:54

А форма не этим занимается?

@Renius 12 ноя 2012 в 09:56

Это уже размазывание логики получается. И нарушение DRY =)

@marazmiki 12 ноя 2012 в 10:01

Я правильно понимаю, что Вы предлагаете сделать что-то типа

if form.is_valid():
    if form.cleaned_data['start_date'] >= form.cleaned_data['end_date']:
        message.error('Неверный интервал') 
    else:
        form.save()

и считаете, что это не размазывание логики и не нарушение DRY?

@Renius 12 ноя 2012 в 10:05

Я считаю, что форма должна передавать сырые данные серверу. Форма занимается приемом данных от пользователя. Форма не должна заниматься обработкой ошибок. Этим должен заниматься сервер приложений.

@marazmiki 12 ноя 2012 в 10:18

Что ж, у Вас есть право на личное мнение :-) Но оно не совпадает со мнением разработчиков джанги, которые считают, что

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"

и кстати, разве форма не является частью сервера приложений?

@Renius 12 ноя 2012 в 10:28

Нет, форма не является частью сервера приложений, т.к. исполняется на клиентской стороне.

| 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 отсутствуют механизмы валидации данных.

@marazmiki 12 ноя 2012 в 10:35

Кажется, разобрались. Мы говорим о разных вещах.

Для меня, как и, надеюсь, для большинства джанго-разработчиков, форма — это то, с чем работаем мы на сервер-сайде. То есть часть джанги. А не какой-то там html-код, за который должны отвечать верстальщики :-)

@Renius 12 ноя 2012 в 10:43

Зато я теперь знаю как утроен родственный разум. Я rails-разработчик.

@marazmiki 12 ноя 2012 в 11:03

А, ясно. На огонёк зашли, или так, потроллить? :-)

@Renius 12 ноя 2012 в 11:09

Упоси святой скотч, никакого троллинга! Я знаю ряд django-разработчиков и уважаю их. Тем более, что теперь я умею их готовить :) Огонек в том, что тема динамических форм полностью не раскрыта, и если кто-то изобретает этот велосипед на костыльном ходу, то не воспользоваться опытом было бы непростительно. Лучше даже сразу застрелиться!

@Renius 12 ноя 2012 в 09:33

Валидация помогает с датами.
Пример с паролем уникален тем, что необходимо одновеременно отправлять.
Да и плохой тон уже спрашивать пароль повторно.

@marazmiki 12 ноя 2012 в 09:37

Валидация помогает с датами.

Что, простите?

@Renius 12 ноя 2012 в 09:42

Вы привели пример с датами. Валидатор не может работать с датами?

@marazmiki 12 ноя 2012 в 09:48

Вы уточните, пожалуйста, какой валидатор?

@Renius 12 ноя 2012 в 09:55

errors = []
if end_date > start_date
errors.push 'end_date больше start_date'
else
update_fields
end

примитивный валидатор

@marazmiki 12 ноя 2012 в 10:01

Именно этим форма и занимается.

@Renius 12 ноя 2012 в 10:08

Форма не должна этим заниматься. Т.к. тем же примитивным фаербагом можно с формой сделать все что угодно и она отвалидированная улетит на сервер. Тогда нужно валидировать данные уже на сервере. Зачем делать двойную работу в двух местах? Еще и тестировать придется разными методами.

@marazmiki 12 ноя 2012 в 10:24

Именно что должна.

Но на клиентскую валидацию действительно полагаться нельзя, поэтому она (валидация) должна происходить на сервере. А JS, который всего лишь упрощает жизнь пользователю, должен всего лишь гонять от клиента серверу введённые данные и обратно, от сервера клиенту, решение сервера о том, верно ли всё заполнено.

Но как бы то ни было, задача валидации лежит целиком на машинерии формы.

P.S. На самом деле, в моделях тоже есть валидация, но это другой вопрос.

@Renius 12 ноя 2012 в 10:32

Не должна, по единственной причине — это не секьюрно.
Что такое машинерия формы… я чота поплыл в терминологии…

@marazmiki 12 ноя 2012 в 11:04

Машинерия — это, грубо говоря, набор механизмов. В нашем случае — это набор классов джанги, ответственных за работу с формами (от генерации хтмл до собственно валидации)

@DirectX 12 ноя 2012 в 06:02

Делал подобный функционал на плагине для jQuery jEditable. Он достаточно простой: для необходимых элементов указываются адрес, куда должен слаться POST запрос. При клике на такой элемент он заменяется на поле редактирования (возможен вариант использовать TinyMCE) после чего шлется обычный POST, куда в качестве параметров приходит id и value. Результат этого запроса, если он не пустой, будет новым значением для элемента.

Подключается скрипт:

<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.

@Renius 12 ноя 2012 в 10:03

А ошибки как обрабатывать?

@DirectX 12 ноя 2012 в 10:20

На сервере — никто не ограничивает в способах валидации. На клиенте — тоже, можно обрабатывать onSubmit stackoverflow.com/questions/2425456/validate-jeditable-field

@vintyara 12 ноя 2012 в 11:42

Что за сайт? Дайте потыкать в живую, заодно и резюме, судя по всему, размещу )

@int22h 12 ноя 2012 в 11:47

Потыкать в живую можно здесь http://resumeo.me/

Зарегистрируйтесь на Хабре, чтобы оставить комментарий