js не причем, тебе нужно рендерить страницы на беке (я так подозреваю вам для поисковиков?), используй джанго темплейты

вот это совершенно использовать не хочется...

Я никогда не делал этого в контексте Django, но на первый взгляд эта штука должна работать: https://github.com/markfinger/python-react

я вот что на счет этого и думал.. попробую запустить

Также я вижу, что есть интеграция с webpack в этом проекте: https://github.com/aleccunningham/django-react

Webpack — это популярный сборщик для морды.

Наверняка, ваши фронтендщики используют его. Они могут помочь немного с ним.

так, а на сегодня проблема с рендерингом вообще актуальна? поисковики, я слышал, поисковики вроде норм JS относятся. Не?

Что за стереотипы? Динамически генерируемые сайты уже давно нормально индексирует

у тебя есть хоть одно приложение на реакте что ты такое рассказываешь?

так, а на сегодня проблема с рендерингом вообще актуальна? поисковики, я слышал, поисковики вроде норм JS относятся. Не?

к пьюр джсу возможно, с реактом дела пока не очень

у тебя есть хоть одно приложение на реакте что ты такое рассказываешь?

Я знаю людей которые знают людей... Ну ты понял Но я уверен что они не врут и они умеют выводить приложения на реакте в топы

понятно

ладно парни, судя по всему пробема есть... для меня, консольщика и бекенщика, она не понятна ;) но решать придется...

Ребята у меня есть вопрос по формы, если кто то изменит аттрибут "name" в форм фиелд MultiDictValueError ошибка будет, например если я изменяю <input name="username" /> на <input name="nousername" /> Ошибка будет. Как зашитить это?

А что ты собрался защищать?

except MultiDictValueError: form. invalid() ?

А что ты собрался защищать?

Да это, имхо, чушь. Кто может на стороне бэкенда переопределить атрибуты??

Дык и я о том же

Я думаю, что он пытается в dynamic fields.

Ну захочет он name поменять, ну вылезет ему 500. А надо что, радугу показать?

Просто не верно задает вопрос.

Ну дождемся первоисточника

name и id - это джанга сама отдает же?

То есть, у нас, вроде в конструктор не передается это?

Ну если ты подаришь как form

Id не валидируются

А там разве вопрос о валидации? Его же нэйминг тревожит, вроде?

class PointsForm(forms.Form): def __init__(self, *args, **kwargs): extra = kwargs.pop('extra') tournament = kwargs.pop('tournament') super(PointsForm, self).__init__(*args, **kwargs) for team in extra: if tournament.single_player is False: self.fields['%s' % team.team_1.id] = forms.IntegerField(widget=forms.TextInput( attrs={'placeholder': 'Очки', 'class': 'form-control'})) self.fields['%s' % team.team_2.id] = forms.IntegerField(widget=forms.TextInput( attrs={'placeholder': 'Очки', 'class': 'form-control'})) else: self.fields['%s' % team.player_1.id] = forms.IntegerField(widget=forms.TextInput( attrs={'placeholder': 'Очки', 'class': 'form-control'})) self.fields['%s' % team.player_2.id] = forms.IntegerField(widget=forms.TextInput( attrs={'placeholder': 'Очки', 'class': 'form-control'}))

Нейминг головного мозга?

Я вот про что. То есть, когда мы заранее не очень знаем сколько полей у нас может быть.

Только у него name

блин ребзя вы предупреждайте когда глаза закрывать, а то больно смотреть

Обычно подобное делается через formfactory

Как вариант. Я просто предложил пример того, что он может хотеть) Филиал Бабы Ванги)

блин ребзя вы предупреждайте когда глаза закрывать, а то больно смотреть

Сорри, это оно САМО)))

Мой бубен в ремонте

1е правило бойцовского клуба - бить по рукам за копипасту =) иначе тех. долг бует бить в бубен

Бро, это мой код)) Гаденько, мгм. Одно из "временных решений" )

как показывает практика - нет ничего более постоянного чем временное. мне доводилось (и не раз) чинить временные решения которым по 5 лет...

ну конечно это дело каждого как писать и что, но лучше же сразу норм сделать если такое решение работает

Нет ничего долговечнее, чем временное

Над этим я и насмехался сейчас) На самом деле, этот костыль упразднен в пользу жыэса в шаблоне.

Блин, в метро(( не сразу отправляется

Так, есть новость, у нее есть описание и заголовок. Есть любой юзер, который может предложить исправить информацию в этой новости. Как такое реализовать?

Да как угодно. js комбинация клавиш, собирает выделенный текст или нужные селекторы (привязать на селекторы нужное из БД - не проблема, да), собираем это всё в какой то массив, скармливаем вьюхе в виде уведомления админу ресурса. Это если нет желания пилить кнопку.

ну, как это сделать, я примерно знаю. Мне вот больше интересно как базу спроектировать. где хранить эти изменения и как

m2m users.is_staff (или кто там у тебя имеет полномочия принимать такие сообщения) на сами запросы.

Я так понимаю нужно реализовать механизм ревизий?

Ну, например ты зашел - решил отредактировать новость и отправить ее , в Википедии вроде так

Мне вот не нравится идея менять статью полностью и сразу сохранять

У меня сейчас похожая задача. Я сделал просто — положил в Git, создал модель Transaction (для мета-полей, там много всякой доп. инфы к транзакции) и просто дергаю Git из приложения. В инстанс Transaction сохраняю идентификатор коммита.

Тут типа-B2B и производительность и лучшие практики deaign patterns мне не критичны в данном случае, ггг.

Но у меня еще полно файлов, не только текст. В целом стейт файлового дерева надо сохранять.

Проще сделать отдельную модель для ревизии с релейшеном на новость и булевым полем на апрув

+ сигнал на пост_сейв если апрув в Тру, то проапдейтить новость

сообщение для администрации выводить с помощью какой нить difflib

http://django-reversion.readthedocs.io/en/stable/index.html думаю попробовать через это реализовать

учти что она знает только за стандартные джанго модели

если у тебя поверх какой-то функционал - оно не будет знать как с ним работать

и при восстановлении - оно восстановит все что было в ревизии включая FK и если фк не будет на момент восстановления - получишь интегрити эррор

Мне вариант с гитом понравился. Возьму на заметку, если что то подобное будет нужно.

а если восстановишь все сразу - то оно заафектит все, и ты получишь по факту фк обьект из ревизии другого обьекта, и данные могут (и в 95% случаев будут) различатся

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

Я хочу создать временный URL-адрес без использования базы данных. Есть идеи?

урл -> вьюха -> кеш?

http://stackoverflow.com/questions/25292052/send-email-confirmation-after-registration-django

Исползую это

Я хочу создать временный URL-адрес без использования базы данных. Есть идеи?

Механика простая - дополнительное поле в профиле, рандомно генеришь строку, проверяешь её в урл. Всё

ERROR: S client not available

дополнительное поле не надо по моему

Ну а как ты собрался детектить пользователя?

Я хочу создать временный URL-адрес без использования базы данных. Есть идеи?

Генеришь хеш и ложишь в редис например

Ключ хеш - значение мейл

Ключ хеш - значение мейл

Не безопасно

Почему

Потому что оно вычисляемо

Щито?

Простой пример - я регаю акк на "Несвою" почту... беру хеш от почты... и вуаля - я на сайте без использования ящика

Привет боты

Хеш генерируется рандомно, юид например

ключ хеш от мыла, значение - юид, в ссылке юид рандомный

и все, не подберешь. а вообще в джанго мире вроде есть пакет с уже имплементированными временными ссылками

только щас не вспомню как он называется

По хорошему счёту у "временной ссылки" должно быть expired_time

По хорошему счёту у "временной ссылки" должно быть expired_time

redis.setex

redis.setex

Я понял уже что ты любишь редис... Но ставить сервак только ради ссылок - через чур

Зависимость от внешних сервисов - не есть хорошо

Другое дело, если б селери какой нить крутился... кеш, сессиии... тогда да

внешних относительно кого? джанги? а база тогда не внешний сервис? редис поставить - 1 минута дела, зато ты сразу получаешь быстрый кей велью и для кеша и для сессий и в том числе для временных ссылок

Чё уж там, гуляж так гуляж - Кролика для селери(потом возможно пригодится), редис для кеша, ссылок, сессий, монгу для динамических моделей, оракл для остальных... В итоге у нас норм бложек получится

а... и ещё эластик для поиска)))

норм

мне нравится

ахаххахах)))

ну хз, я не считаю редис оверхедом, имхо он вообще ничего не стоит в плане установки и настройки

зато дает много бенефитов

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

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

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

а где граница между "необходимостью всего проекта" и "свистоперделка"?

а где граница между "необходимостью всего проекта" и "свистоперделка"?

в адекватном восприятии происходящего разработчиком

Например, если на проекте используются только фильтры по каким то полям модели, ты ж не станешь впиливать поисковый движок? И наоборот, если основной целью проекта является поиск инфы в огромной бд, ты же не станешь это делать sql запросами