Докер лучше до сервера, а на сервере Rkt

Докер лучше до сервера, а на сервере Rkt

Чем лучше?

Rkt пока не поддерживается со стороны PyCharm'а

только Docker

Rkt работает из Virtualbox'а

тогда как Docker for Mac использует https://github.com/mist64/xhyve

это более правильное решение для виртуализации на OS X

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

всем привет у меня в форме используется самодельный виджет. при этом initial значение поля виджета теперь всегда первое по порядку, а не то, что у инстанса объекта. как правильно переопределить поле?

всем привет у меня в форме используется самодельный виджет. при этом initial значение поля виджета теперь всегда первое по порядку, а не то, что у инстанса объекта. как правильно переопределить поле?

Попробуйте так для формы: def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self.fields['your_field'].initial = your_data

Убью нахуй

self.initial дергайте

@arisudesu внушает впечатление здравого человека

Но не всегда

реально ребята прочитайте two scoops of django и перестаньте страдать хуйнёй

большая часть вопросов решается там

Убью нахуй

Неужели то, что я написал настолько говнокод?

Попробуйте так для формы: def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self.fields['your_field'].initial = your_data

В итоге переписал виджет

реально ребята прочитайте two scoops of django и перестаньте страдать хуйнёй

В двух рожках не пишут свои виджеты со своими чойсами

Неужели то, что я написал настолько говнокод?

ну есть же self.initial

http://avilpage.com/2015/03/django-form-gotchas-dynamic-initial/

эти формы на столь кастомные, что извратиться можно и без переопределения self.initial

короче не стоит инишиал перебивать в таком случае

ну все равно, если стоит задача дергания инишл значений в моделформе - ссылка выше

имейте в виду)

Делаю небольшой сервис с rest api для гет запросов у всех моделей определен метод to_json: def to_json(self): return dict(schedule_id=self.id, group=self.group.to_json(), year=self.year, semester=self.semester, exercises=[exercise.to_json() for exercise in self.exercise_set.all()]) я делаю чет неправильно?

а в чем собсна вопрос?

year=self.year <- приводи лучше к таймстампу

конечно, если это дата, а не просто интовое значние, вида 2001

в данном случае это именно год, так как год+семестр однозначно идентифицируют расписание

вопрос собсна в том, что я, кажется, сейчас наткнулся на неприятную штуку и вот думаю как её решить

если в to_json название поля не совпадает с фактическим

то есть если будет group_number = self.group

то когда я буду делать put, и передавать Json, то нужно придумать обратную операцию

да и когда буду делать post с созданием новой модели

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

и если вот такая ситуация в to_json

то есть если будет group_number = self.group

то при таком способе, как я щас использую: query = json.loads(response) new_model = model(**query) new_model.full_clean() new_model.save()

то вылетит ошибка, мол, group_number поля нет

а ещё вопрос по изменению полей модели сейчас я делаю вот так получаю через json словарь полей и model_instance.__dict__.update(**new_dict)

насколько это правильно?)

ну как то кривовасто

стоит сделать какой-нибудь from_json в модели и делать обратную операцию, да?

model_to_dict есть же

Ну или нахуячь базу, которая будет все объявленные поля сериализовать

model_to_dict не то же самое что и __dict__?

Зачем в django нужен APPEND_SLASH?

Точнее, почему post-запросы обязательно должны уходить на url с / в конце

Зачем в django нужен APPEND_SLASH?

https://github.com/django/django/blob/master/django/contrib/redirects/middleware.py#L38

понял куда читать

спасибо

у джанговцев принято делать урлы со слэшами на конце

а чтобы они работали лучше есть вот эта опция

если человек набрал без слэша - он подставляется

то есть он тупо редиректит на тот же самый урл, но со слэшем на конце

а какая у всего этого практическая причина?

допустим, у тебя урл вида porn.ltd/tags/anal/ , если человек наберёт без последнего слэша и эта опция не включена - он получит 404

а если включена - его редиректнет на страницу со слэшем на конце

если у тебя все урлы без слэша на конце - то тебе эта опция не нужна или нужна обратная ей

вот мне, кстати, была бы полезнее именно обратная настройка (чтобы убирал /, если вдруг на конце напишут / )

не понял всё равно практической причины

ну то есть безопасность там или че

у тебя есть urls.py

чисто приведение к одному виду?

вот там на конце если у тебя есть слэш - то если пользователь наберёт без слэша - нужная страница не откроется

а, кажется понял

это типа такая жесткая установка, что url со слэшем и без слэша - разный

а если эту опцию включить - он автоматически добавит редиректы на все урлы, на конце которых слэша нет

это он по умолчанию как раз разный)

ну вот я про умолчание и говорю)

ну вот полезнее была бы обратная опция

чтобы убирал слэши когда они есть

потому что многие по умолчанию сейчас делают урлы без слэшей на конце

а некоторые юзеры любят писать со слэшами если копипастят

а если делать это как разные страницы, наверное, для SEO плохо

получится, что каждая страница сайта в двух экземплярах на сайте

О, лев

Здравствуйте! Царь. Очень приятно, царь. Очень приятно, здравствуйте, царь. Очень приятно, царь. Царь очень приятно. Царь. Очень приятно. Очень приятно...

Король лев

Нудно

Как то

Даже льва не видно

тут чатик про Django, а не про львов)

[но если кто-нибудь решит сделать чатик про львов - приглашайте)) ]

вы заметили, кстати, что 1.10.1 вчера вышла?

https://docs.djangoproject.com/en/1.10/releases/1.10.1/

чейнджлог длиннее, чем у релиза

чейнджлог длиннее, чем у релиза

хорошее правило для сисадмина - не ставьте версию, кончающуюся на 0. Вот именно из-за таких фокусов

Надо будет завтра попробовать

А я вообще на 1.8

Аналогично, один проект на 1.9 пересадил для фич с GIS и JSONField