БетаЛаборатория - внеочередной IT-блог

Давно собирался сделать возможность вводить Float разделенные не точкой, а запятой, да никак руки не доходили. Но, сегодня все-таки пришлось сделать, поскольку для заказчика это оказалось критично. В принципе, данная задача решена в отдельном бранче Django, однако я предпочел сделать более простое, но менее полное и гибкое решение - создал специальный FormField. Все что он делает - это заменяет в полученных от пользователя данных запятую на точку, после чего передает управления оригинальному FloatField.

from django import forms

class FloatFieldWithComma(forms.FloatField):
	def clean(self, value):
		# Проверяем задано ли вообще значение
		if value:
			# Если да - заменяем запятую на точку
			value = value.replace(",",  ".")
		return super(FloatFieldWithComma,  self).clean(value)

Соответственно, если вы используете ModelForm, вам надо будет переопределить поля с плавающей точкой

# Модель
class MyModel(models.Model):
	name = models.CharField(max_length=150)
	price = models.FloatField()

# Форма для модели. В таком виде форма будет требовать
# чтобы разделитель обязательно был точкой.
class MyModelForm(forms.ModelForm):
	class Meta:
		model = MyModel
# А с переопределенным полем price валидными будут и
# точка и запятая
class MyModelForm(forms.ModelForm):
	price = FloatFieldWithComma()
	class Meta:
		model = MyModel

Недостатки этого метода в том, что он, во-первых, не прозрачен для django-admin - чтобы все работало, потребуется переопределять формы всех AdminModel в которых нужен ввод чисел с плавающей точкой. А во-вторых, вывод значения поля будет по прежнему с точкой. На данный момент меня такое решение устраивает, однако я попробую придумать что-то более гибкое.

Ну вот, переделал django-приложения для работы с WYSIWYG-редакторами. Первоначальная реализация была достаточно кривая, к тому же давала возможность работать только с FCKEditor 2, который уже достаточно устарел. Кроме того, после некоторых оптимизаций работы nginx, она перестала работать =/ Новое приложение уже более корректно, хотя еще тоже не доделано. На данный момент еще не реализована нормальная работа с https, однако это проблема не только данного приложения, но и всей системы в целом.

От использоваия FCK для себя я отказался в пользу TinyMCE. Но в самом приложении я реализую постепенно поддержку минимум 3-4х различных редакторов, после чего выложу это все в open-source. Увы, пока мне приходится все это делать одному. Сейчас я перешел к более-менее активному поиску помошника по django (нужно по работе), но насколько быстрым и успешным будет этот поиск не знаю. Сначала я очень понадеялся на проект http://djangopeople.net, но увы... Как оказалось большая часть москвичей, да и россиян вообще, именно к джанго отношения не имеют. Не совсем мне понятна их мотивация для регистрации на таком сайте, но судя по всему, просто чтобы дополнительно "засветиться"  везде, где могут обитаться потенциальные заказчики. Грустно...

PS: начинаю морально готовиться к тому, что сотрудников надо будет искать не в нашей стране.

 

• 1. Клиент запрашивает файл у веб-сервера (frontend, в нашем случае это nginx).
• 2. nginx перенаправляет запрос к Django (backend), согласно параметрам локации (location), которой соответствует URI запрошенного файла.
• 3. Django принимает запрос, обрабатывает URL и возвращает nginx'у ответ с кодом 200, содержащий реальный путь до файла (в заранее заданной локации) в заголовке X-Accel-Redirect, а также тип содержимого файла в заголовке Content-type, основанный на расширении изначального имени файла.
• 4, 5, 6. nginx обрабатывает путь в X-Accel-Redirect и в ответ на исходный запрос (пункт 1) клиента передаёт ему файл из директории, соответствующей локации, если файл найден. Заголовок Content-type, полученный от Django, при этом сохраняется.

    server {
    listen mysite.ru:80;
    server_name mysite.ru www.mysite.ru;

# Нам совершенно не обязательно проксировать все запросы.
# Поэтому ограничиваемся проверкой запросов вида
# http://mysite.ru/media/upload/some_file.ext

# Передаём изменённый GET-запрос Django. В ответ мы должны получить ответ с
# заголовком X-Accel-Redirect.
    location /media/upload {
        rewrite ^/media/upload/(.*) /nginx/?filename=upload/$1 break;

        fastcgi_pass unix:/path/to/django's/fcgi.sock;
        include /etc/nginx/fastcgi_params;
    }
 

# Эта локация отражает реальный путь до директории хранилища наших файлов.
# Именно сюда Django будет ссылаться в X-Accel-Redirect.
# Прямой доступ к файлам клиентам сайта запрещён (для этого нужна директива internal).
    location /sha1storage {
        internal;
        alias /path/to/project/media/sha1storage;
    }

# Запрещаем  клиентам сайта прямые запросы к Django в локацию /nginx
    location /nginx {
        internal;
    }
 

# Запрещаем клиентам сайта прямой доступ к файлам хранилища в обход Django
    location /media/sha1storage {
        internal;
    }

# Локация с файлами, доступными для загрузки клиентам сайта не из sha1storage.
# Сюда Django перенаправит запрос посредством X-Accel-Redirect, если не
# найдёт файл в sha1storage.
    location /upload {
       internal;
       alias /home/www/www51/betalabs.ru/media/upload;
    }
}

INSTALLED_APPS = (
    'sha1storage',
)

# Если хотите использовать это хранилище как основное, можно указать параметр DEFAULT_FILE_STORAGE.
DEFAULT_FILE_STORAGE = 'sha1storage.storage.SHA1FilenameFileSystemStorage'

urlpatterns = patterns('',
 (r'nginx/', 'sha1storage.views.get_real_filename'),
);

• Администратор - пользовател обладающий абсолютно всеми правами. В данном случае это я.
• Авторы - пользователи, имеющие возможность публиковать записи.
• Читатели - могут читать все записи, комментировать их, участвовать в опросах ну и все такое прочее.