Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
group_required decorator
Here is a decorator that I came up with to augment the already available login_required and permission_required decorators. This one takes a group name and makes sure the logged in user is a part of it. def group_required(group_name, login_url='/accounts/login/'): def wrap(view_func): def in_group(request, *args, **kwargs): from django.contrib.auth.models import Group try: group = request.user.groups.get(name=group_name) except Group.DoesNotExist: [...] -
Django Developers Needed
Calling all Django developers looking for work! I’m looking for some people to rely on for freelance work, as well as scouting a full time position near San Diego. -
byNotes launched
I've just launched the new geomicroblogging site I mentioned a few days ago. It still isn't as powerful as FireEagle, since the web API is still not ready, but I expect to finish it by next week. However, there are also additional features not present in FireEagle (according to what I've read, since I can't try FireEagle): You can send messages. You can send events, and when people reply to them they can specify if they're attending. You can also send links, with oEmbed support. You can build a network of friends and send them private notes. You can become a fan of someone and you'll receive his public notes (like following someone on twitter, but you can also know where he is). You can update your position only for some of your friends, the rest of them will see your previous position. Registration with OpenID is supported. Registration is currently open to everyone, but I'm going to close it as soon as there are users enough for doing some real-world testing. Wanna try it? Go ahead and start geomicroblogging today. As for the source code, I'm not sure if I'll release all of it. However, there are some portions … -
Código do site disponível para baixar
Como prometido anteriormente, o acesso à leitura no sistema de controle de versões deste website foi liberado. Isso quer dizer que agora é possível baixá-lo. Para tal, você precisará do Bazaar instalado (provavelmente existe um pacote para seu sistema, verifique na página de download do mesmo). O site foi escrito em Python utilizando o framework de desenvolvimento web Django, portando será necessário tê-lo instalado também para caso queira testá-lo em seu computador. Siga as instruções no Guia de Instalação. Caso ainda não conheça o Django, talvez seja interessante o estudo de sua documentação para entendimento do código. Baixando Para obter o código do site, utilize a ferramenta de linha de comando bzr: bzr branch http://code.taurinus.org/sementeproject/mainline/ sementeproject O código em http://code.taurinus.org/ está sendo disponibilizado em um "dumb server", então não espere por uma boa performance. Executando Antes de mais nada, você precisará também dos seguintes pacotes instalados em seu PYTHONPATH: Diário Tagging Comment Utils Template Utils Será necessário também o uso da biblioteca CSS libcss-taurinus, seus arquivos deverão estar em media/css/lib/. Experimente fazer assim: bzr export http://code.taurinus.org/libcss-taurinus/mainline/ sementeproject/media/css/lib/ Enfim, para rodar o projeto localmente, execute o seguinte comando: sementeproject/sementeproject/manage.py runserver Mais informações no site do projeto. -
Django Software Foundation
The Django guys have scored another milestone today with the creation of the Django Software Foundation. Being a huge Open Source advocate I love hearing great news like this. You can read more about the foundation at: Announcing the Django Software Foundation New Foundation for Django On an unrelated note, an article I wrote for LinuxPro Magazine last November about using Perlbal was recently put online. You can read it at The Juggler -- Let the nimble Perlbal webserver keep your traffic in balance . -
Olá mundo!
É com muita satisfação que, enfim, coloco meu website pessoal no ar! Quem me conhece sabe que há vários anos estou pelejando por isso e, felizmente, hoje foi o dia. Devagar e sempre! Assim as coisas vão acontecendo(?). Como podem perceber, o formato do site é um weblog. Procurarei escrever sobre as coisas que estou envolvido no dia-a-dia, mais especificamente com Software Livre, GNU/Linux, Administração de Sistemas, Desenvolvimento de Software e, eventualmente, assuntos relacionados à música, vegetarianismo e movimentos sociais. O site foi desenvolvido apenas com ferramentas livres (Emacs, Gimp...) e com o auxílio do framework web Django. Algumas aplicações para Django também foram fundamentais para a conclusão do site: Diário Tagging Comment Utils Template Utils O código do site também está disponível como software livre (GPLv3) e você pode visualizá-lo através do site do projeto. Em breve liberarei o acesso ao controle de versões para que seja possível baixá-lo. A idéia é que o código sirva de referência àqueles que estão estudando Django e para quem possui interesse em um site pessoal utilizando este framework. Toda crítica é muito bem-vinda! Minha pretensão é deixar público o conhecimento que adquirir ao longo do tempo e também aprender com os outros. … -
A better(?) serialization framework: part 3
I think I've finally found the perfect syntax for defining new serializations in your application code. You no longer will need to return the element name. Instead, it'll be taken from the function name, but you can override it via decorator. However, there's an exception to this rule. The default function will always return the object class name into lowercase. In addition, there's a new decorator for extending a serilization. Let's see how it looks: from wapi import serializers class UserProfileSerializer(serializers.BaseSerializer): @serializers.objname(name='my_friend') def friend(self, obj, *args, **kwargs): return { 'username': obj.user.username, 'avatar': 'http://bynotes.com/_m/avatars/%s' % obj.avatar, } @serializers.objname('my_friend_location') @serializers.extends('friend') def friend_position(self, obj, *args, **kwargs): return { 'position': { 'latitude': 5, 'longitude': 9, } } from notes.models import UserProfile serializers.register(UserProfile, UserProfileSerializer) As you can see, now serializations can be extended in the same way they are created and you won't need to write the object name again if it matches the function name. On the other hand, I've finally decided to bundle this serializers as part of the (soon-to-be-released) wapi application, which provides a foundation for exposing web apis in an easy way. -
Vagas para Freelancer Django, Webdesigner e DBA
Estou a procura de bons profissionais para trabalharem comigo em alguns projetos que participo. A princípio, necessito de profissioanais com conhecimentos em Python (Django), Webdesigner (HTML, CSS, JavaScript, Ajax e Design em sí) e DBA para banco de dados MySQL. De preferência que seja um candidato que more no eixo São Paulo – Rio de [...] -
A better(?) serialization framework: part 2 (first alpha release)
I've made some progress on the serialization framework and I think it's ready for an alpha release. Here is the code, but I suggest you to finish reading this entry, since there are a few changes since the last post :). In first place, I decided to remove backwards compatibility, because these serializers are totally different than the ones in Django. Django serializers are clearly designed for exchanging full objects between applications or dumping the object database into a file. They happen to be usable for exposing a web API, but that's not their main purpose. On the other hand, these serializers are designed with a web API framework in mind. They are not intented for exchanging full objects, instead they intend to help you exposing data for your web API clients. That's a totally different purpose and I think both things don't mix well. In addition, I like the UNIX design philosophy, do one thing and do it right. As for importing this code into Django, I think there's no problem keeping both serialization frameworks. In my humble opinion, these newserializers should replace the current serializers, because the former have a potentially wider audience. I don't find myself needing … -
Aprenda o Google App Engine no ShowMeDo
Tem muita gente falando do Google App Engine, realmente a idéia é bastante interessante e não é complicado para desenvolver uma aplicação (se você tiver conhecimentos de Python). Aproveitar todo o poder de processamento do Google para criar páginas dinâmicas sem se preocupar com a infra estrutura de alta disponibilidade é o sonho de qualquer [...] -
A better(?) serialization framework
The current Django serialization framework is not good enough for me. My current annoyances are: You can only serialize object fields. If you have defined some properties over the elements, you can't serialize them. You can not properly nest fields (e.g. serialize the user profile and include the username, you'll only get the foreign key) There's no way to configure some "presets". If I always serialize a class with the same fields, I need to write fields=('foo', 'bar') multiple times (where's DRY when you need it?). You cannot pass arguments to serializations. This could seem like something strange, but I find it usefull and others might do. E.g.: I'm currently developing a geomicroblogging site (yes, I've coined that term - 0 hits on Google right now -, think of it like Twitter+Pownce+FireEagle). One of the API endpoints returns where your friends are, but their locations depend on the viewer because you can send your position privately to just one of your friends (the rest will see the previous one). Let me say this serialization framework is useful for passing raw objects between multiple applications understanding the format, since you can do deserialization on the data and get the exact object … -
Django 1.0 roadmap and timeline
Finally we have a Django 1.0 roadmap and timeline. Jacob Kaplan-Moss posted today on Django devolopers. I must say this roadmap seems very realistic and the only thing that I will miss is the aggregation support, that is promised to be released in a future version, maybe in 1.1. -
Django 1.0 roadmap and timeline
Finally we have a Django 1.0 roadmap and timeline. Jacob Kaplan-Moss posted today on Django devolopers. I must say this roadmap seems very realistic and the only thing that I will miss is the aggregation support, that is promised to be released in a future version, maybe in 1.1. -
The Real Problem with Django
The Django development team does not receive enough credit. Thank you: Adrian, Simon, Jacob, Wilson, Malcolm, Georg, Luke, Russell, Robert and the rest. -
Shortcutting render_to_response
render_to_response is [supposed to be] a shortcut. But when you are using RequestContext, you end up with lots of lines reading like this: render_to_response('template.html', variables_dict, context_instance=RequestContext(request)) I can type fast, but I don't like typing the same code again and again. Maybe I'm a DRY fanboy, but let's hope that's not the case. Over the last few months I've been using some techniques for avoiding typing context_instance=RequestContext(request) after every return statement, however I still haven't found the perfect one, since there's always a tradeoff between flexibility and the number of characters you have to type. So I think it's time to make an entry about it, get some feedback and post the results to django-dev. The most simple approach: wrapper function It's not pretty, nor pythonic, but it's simple and effective as hell. Just define a wrapper function and call render_to_response from it: def my_render(template, variables_dict, request): return render_to_response(template, variables_dict, context_instance=RequestContext(request)) The object oriented way: inheriting from HttpResponse This is one of my favourite approaches, since it doesn't depend on render_to_response. class RenderedResponse(HttpResponse): def __init__(self, template, request, items = {}, **kwargs): t = loader.get_template(template) super(RenderedResponse, self).__init__(t.render(RequestContext(request, items)), **kwargs) In addition, this lets you add some template caching very easily: class … -
About Django and the importance of releases
My favorite Python web framework, Django, has not been updated for a long time. The most current release, 0.96, was released in March 2007. This is a very long time, when you're in the market of web frameworks. This doesn't seem to bother a lot of people, as the common answer in the django community seems to be just to run the trunk version (development version). I for one doesn't like that solution. And here are some of the reasons why. Some of the problems with running a development version When a security release is made, I cannot just update, but need to merge the change in, in all of my installations. An update could maybe break my existing code with backward incompatible changes. It's easier to tell my co-workers that our projects will run 0.96, and not r6389 for one project and r7291 for another (+ a couple of security patches). That's okay if you are a single-person team working on a single project, but not when you have several people and projects. Developers are afraid to commit new things to trunk, because a lot of users will be disappointed when they eagerly update their repositories each morning just … -
About Django and the importance of releases
My favorite Python web framework, Django, has not been updated for a long time. The most current release, 0.96, was released in March 2007. This is a very long time, when you're in the market of web frameworks. This doesn't seem to bother a lot of people, as the common answer in the django community seems to be just to run the trunk version (development version). I for one doesn't like that solution. And here are some of the reasons why. Some of the problems with running a development version When a security release is made, I cannot just update, but need to merge the change in, in all of my installations. An update could maybe break my existing code with backward incompatible changes. It's easier to tell my co-workers that our projects will run 0.96, and not r6389 for one project and r7291 for another (+ a couple of security patches). That's okay if you are a single-person team working on a single project, but not when you have several people and projects. Developers are afraid to commit new things to trunk, because a lot of users will be disappointed when they eagerly update their repositories each morning just … -
django pluggables
I have struck goldmine ! Bored today with another plone innard hacking session I began hunting around on the internet for a django plugins site. I came across this site called http://www.djangoplugables.com/ ! This is exactly what I am looking for with a cute little plug in socket as a logo! I am astounded by the speed in which django has grown ! I have coded some applications with django the past and I can say I like the feel of using it. It is has what I need in terms of a web application framework and is closer to the python metal than plone or zope will ever hope to be. Don't get me wrong, I still have a soft spot for zope and I truly hope that zope 3's modularity will be more elegant than the monolithic monstrosity that zope 2.x is.Today while looking at the pluggable site, has given me much more confidence of adopting django as one of the stable technologies to deliver web applications in my company's offerings. Coming from a background that have used both I can attest to why a senior python programmer would love django. I hope though the django community get … -
Distribuindo tabelas MySQL em vários servidores
Os frameworks para desenvolvimento web como o Django possuem um ótimo ORM, facilitando muito a criação de aplicações rápidas e eficientes. Da mesma forma que facilita o desenvolvimento, atrapalha em alguns pontos, como por exemplo se o desenvolvedor desejar utilizar mais de um banco de dados para a mesma aplicação. Embora seja possível fazer, as [...] -
StaticGenerator for Django Updated (1.3.1)
Version 1.3.1 of StaticGenerator is out. You can now get it using easy_install. The big news is that StaticGenerator now leverages Django’s awesome Middleware system to more efficiently create the static files. -
Django Meetup Postmortem
Thanks to the organizer Jannis, last Friday German djangoers met successfully, got some beer at Schleusenkrug in Tiergarten, Berlin, and became better aquainted with each other. We discussed the latest actualities like licenses, project deployment, business models, the future of Django, who from the gods of Django said what in which blog, and other geeky stuff.If you want to get in touch with German djangoers, you can join the #django-de IRC channel on irc.freenode.net. Also you can subscribe to their blogs at django-de.org. -
DjangoSites is 1337
It's kind of nerdy and geeky, but we've just passed the 1337th approved site on DjangoSites. The lucky submission was Chinet, the website for a set of environmentally friendly disposable tableware. From glancing at the websites as they're approved, I'm noticing the quality of design of many websites improving compared to the more 'tech-friendly' submissions when the project first began. It's a great sign that Django is reaching further into everyday website development, which can only mean good things. Here's to another 1000+ sites! -
DjangoSites is 1337
It's kind of nerdy and geeky, but we've just passed the 1337th approved site on DjangoSites. The lucky submission was Chinet, the website for a set of environmentally friendly disposable tableware. From glancing at the websites as they're approved, I'm noticing the quality of design of many websites improving compared … -
Readout of TypoScript with eID and BE-Modul
Sometimes you have to get TypoScript values in different places. The following will illustrate two problems that proved me. TypoScript with eID The script being called via eID is kind of lightweight and does not load a fully features TYPO3 core. User as well as database are initialized quickly but if you want to use values from TypoScript this unfortunately cannot be achieved with two lines of code. You at least need to transfer the page id to the eID script - I'm using a GET variable - to correctly initialize the TSFE. Then just instantiate a tslib_fe class, connect to the database, initialize the user, template and config and you're done: // eID specific initialization of user and database tslib_eidtools::connectDB(); tslib_eidtools::initFeUser(); // initialize TSFE require_once(PATH_tslib.'class.tslib_fe.php'); require_once(PATH_t3lib.'class.t3lib_page.php'); $temp_TSFEclassName = t3lib_div::makeInstanceClassName('tslib_fe'); $GLOBALS['TSFE'] = new $temp_TSFEclassName($TYPO3_CONF_VARS, $pid, 0, true); $GLOBALS['TSFE']->connectToDB(); $GLOBALS['TSFE']->initFEuser(); $GLOBALS['TSFE']->determineId(); $GLOBALS['TSFE']->getCompressedTCarray(); $GLOBALS['TSFE']->initTemplate(); $GLOBALS['TSFE']->getConfigArray(); Now access the data in the well-known way: $GLOBALS['TSFE']->tmpl->setup['plugin.']['extensionkey.']['your_value'] By the way: with this line of code you can readout the TypoScript in not fully initialized plugins, too. TypoScript in backend modules Sometimes there is the necessity to access TypoScript in backend modules, e.g. when sending an email to readout the sender. The process is similiar to … -
Readout of TypoScript with eID and BE-Modul
Sometimes you have to get TypoScript values in different places. The following will illustrate two problems that proved me. TypoScript with eID The script being called via eID is kind of lightweight and does not load a fully features TYPO3 core. User as well as database are initialized quickly but if you want to use values from TypoScript this unfortunately cannot be achieved with two lines of code. You at least need to transfer the page id to the eID script - I'm using a GET variable - to correctly initialize the TSFE. Then just instantiate a tslib_fe class, connect to the database, initialize the user, template and config and you're done: // eID specific initialization of user and database tslib_eidtools::connectDB(); tslib_eidtools::initFeUser(); // initialize TSFE require_once(PATH_tslib.'class.tslib_fe.php'); require_once(PATH_t3lib.'class.t3lib_page.php'); $temp_TSFEclassName = t3lib_div::makeInstanceClassName('tslib_fe'); $GLOBALS['TSFE'] = new $temp_TSFEclassName($TYPO3_CONF_VARS, $pid, 0, true); $GLOBALS['TSFE']->connectToDB(); $GLOBALS['TSFE']->initFEuser(); $GLOBALS['TSFE']->determineId(); $GLOBALS['TSFE']->getCompressedTCarray(); $GLOBALS['TSFE']->initTemplate(); $GLOBALS['TSFE']->getConfigArray(); Now access the data in the well-known way: $GLOBALS['TSFE']->tmpl->setup['plugin.']['extensionkey.']['your_value'] By the way: with this line of code you can readout the TypoScript in not fully initialized plugins, too. TypoScript in backend modules Sometimes there is the necessity to access TypoScript in backend modules, e.g. when sending an email to readout the sender. The process is similiar to …
