Oduvan’s Web Blog

при создании нового джанго проекта я всегда выделяю две папки apps – для моих апов и compat – для сторонних апов, к разработки которых я не имею никакого отношения. Идея в том, что эти апы всегда остаются неприкосновенными для меня, и единственной точкой расширения остаются сеттингсы и возможно доп параметры, при инклюде урлов.

А представьте, что вы создаете апу с именем catalog, ее вы потом хотите выложить в общее пользования, и необходимо для нее сделать больше точек расширения. Структура такого апа может быть

• catalog
• urls.py
• views.py
• models.py
• settings.py
• tests.py

для 4 первых файлов можно просто вконце файла добавить строку, которая станет универсальной точкой расширения. Например для views.py

таким образом, если кто-то будет использовать Вашу апу — точкой расширения будет дополнительная апа ex_catalog, в котором вы можете переопределить некоторый функции из view.py, и при этом ex_catalog не надо добавлять в список апов в настройках.

А теперь главный вопрос этого поста. Почему так не делают?

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

И вот некоторые интересные ссылки.

Виджет на морде. Александр Кошелев рассказывает о создании Яндекс Афиши. Как по мне, то вдохновляет.

стать я по старее, но примерно про тоже и с той же целью.

Куда все идут. Иван Сагалаев. Рассказывает о другом яндекс сервисе.

К слову о предудущей моей статье.

Global Interpreter Lock: факты и мифы

И три небольших статьи Александра о наследовании.

И на последок не джанго JavaScript language advanced Tips & Tricks

как делать group by в моделях. В доках вещь не очевидная. Работает только с транком.

Если вы хотите пользоваться всеми переменными окружения Django, но при это “находится” не врутри какой либо вьюхи, т.е. код запускается не через Http запрос, а к примеру – через крон, то начинаться этот скрипт у вас должен такими словами, и лежать он должен в коре вашего проекта:

Успехов…

Сегодня из интереса написал небольшой модуль сериализации в ХМЛ. На скорую руку. Как по мне – довольно элегантное решение. Как думаете?

Вот, как его мона юзать:

что мне надо от логов:
1) конешно выводить точку запуска + время в каждом запускаемом логе + дополнительная инфа, как правило у разных проектов она разная.
2) выводить не только сроку, но и более сложную структуру.
3) разные функции для логов ( info, error, debug,trace) чтоб на внешнем серваке отказываться от определенных из них, причем делать этот без потери скорости.

sub _log{
my ($self,$type,$text,$cl) = @_;
my @tt = localtime;
my ($pack,$filename,$line) = caller(1);
my ($topack,$tofile,$toline) = caller($cl) if($cl);
$line = "($type)".POSIX::strftime("%d,%h %H:%M:%S",localtime)." $filename($line) ";
if($cl){
my ($topack,$tofile,$toline) = caller($cl) ;
$line.= "{$tofile($toline)}";
}
# тут линию можно дополнить своими
open my $fh,'>>'.MyProject::Conf::LOGFILE;
print $fh $line.$text."\n";
close $fh;
}

my $alog = MyProject::Conf::LOGS;
my $clog = MyProject::Conf::CLOGS;

no strict 'refs';

foreach my $ll (@$alog){
my $method = lc $ll;
if(grep {$_ eq $ll} @$clog){
*{$method} = sub{my $self = shift; $self->_log($ll,@_)};
*{$method.'_dump'} = sub{my $self = shift; my $text = shift; my $data = shift; $self->_log($ll,$text.':'.Dumper($data),@_)}
}else{
*{$method} = sub{};
*{$method.'_dump'} = sub{};
}
}

немного по коду… MyProject::Conf::LOGFILE – тут просто лежит абсолютный путь к файлу логов.
MyProject::Conf::LOGS – тут лежит массив имен всех доступных логов, я использую ['INFO','DEBUG','DERROR','TRACE']
MyProject::Conf::CLOGS – массив логов которые необходимо выводить. Так я сделал потому, что не в се используемые логи необходимо выводить в данном запуске проекта.

цикл идущий после no strict ‘refs’;

просто заполняет функции. имен всех функций переводятся в нижний регистр. + добавляется еще и функция dump, для info она будет info_dump, которая кроме передой строки, в лог еще запишет передаваемую структуру, выводимую с помощью Data::Dumper