Search posterous

Search all posts and users. Type a name, type a favorite song title, whatever! See what comes up.
  

More posterous blogs











More recommended blogs »

Here are posterous posts filed under django...

nanda says...

Just recently I have been told by my boss to work on a feature. After a few commits to the sandbox, code-reviews and QA, suddenly, I have been told that this feature might be helpful only for a certain client and some clients might not need it. But the feature should be part of the core always(as its been already developed, and for future needs). I didn't know what to do or how to proceed. Later my boss told me to have a global on-off functionality which will be enabled for certain clients and disabled for certain clients. Thats good. And that solved the issue.

Did you notice anything BIG in this? I do.

With just one single flag, the whole feature will be treated as a PLUGIN. Isn't that great. Plugin development. These days, popular tools like Django, Eclipse and many others are resorting to the same philosophy. Plugin-related development or Loose-Coupling. Because its completely flexible and makes sense. If you dont like anything(or any component), just put it off. Its that easy(ofcourse proper dependancies need to be handled, and is always the case with any code anyway).

Now, lets think about it laterally. From the Open-Source perspective.

Let me give you an example, so its clear. These days I'have been using Wingware(instead of Eclipse) for all my development needs. As you may now, its proprietary and doesn't have any plugins concept. So if I want a good graphical svn merge tool I need to put a request to wingware teams to develop one. If I want a simple search utility to search files in my project using a wildcard expression, again I need to put a request to wingware teams to develop one. I made a list of this. So no plugins, no nothing. Thats the killer feature of Eclipse. Plugin development. You have a whole site dedicated for that and growing

Thats the power of Plugins. Enough for now. Got an opinion on this? Leave a comment.

Filed under: django

hdknr says...

http://djangopony.com

Filed under: Django

Ted says...

Representing dates and times as HTML elements is probably one of the most frustrating parts of web development. My friend and fellow Djangonaut Ben Kreeger has posted an excellent writeup on how to integrate the django.contrib.admin date/time picker widget into your own Django form classes. Check it out here at his blog.

Filed under: django

hdknr says...

Filed under: Django

hdknr says...

Filed under: Django

nanda says...

Note: Just recently I found a thread in one of the popular forums, asking a similar question. So felt like giving this solution(which I developed long back).

So login as any user into a website ?

Hey dont get me wrong! I am not telling a way to hack into Django's authentication system or steal the password of a user on a Django Site.

If you are an admin of a django site and many times it feels to visualize or experience how a normal website user actually sees different pages of your website. So to get this done, we create a normal user (just for testing purposes) and check the same, which is good. But sometimes we need to actually login as the same person to resolve a issue or to trace a particular exception which only one user or a specific set of users are experiencing.

Enough said. So you need to login as "Anybody" to gain access to their account/pages. Ofcourse you are site admin, and for some non-ambigous, quite-healthy purposes, you need a tool to get that done. Here it is. The django authentication module lets that possible.

Public Clone Url: git://gist.github.com/242439.git

def login_using_email(request, email):
    '''DONT EVER USE this method for normal purposes. This is only there, for debugging specific problems related to users'''
    from django.contrib.auth import get_backends
    backend = get_backends()[0]
     from django.contrib.auth.models import User
    user = User.objects.get(email=email)
    user.backend = "%s.%s" % (backend.__module__, backend.__class__.__name__)
    from django.contrib.auth import login as django_login
    django_login(request, user)
    #set_any_extra_session_variables(request)

Usage:login_using_email(request, "example@example.com")

I have mentioned only the helper or core method which is responsible for the actual user "logging-in" simulation. Proper view permissions(remember I mentioned only admins should use this) can be wrapped around it. Any thoughts on improving it? Always invited....

 

Filed under: django

clintecker says...

A "server description" and "deployment testing tool" from Eric Holscher and World Online.

Filed under: django

hdknr says...

django-openidで使われていた技。知ってて当然なんですかね。django-openidはさらにURLConfを動的に作るとかしている。

urls.py


from django.conf.urls.defaults import *
from django import template
from django.http import HttpResponse
#
class Account(object):
    _t = '''<html><head><title>Account</title></head>
        <body>
        <h1> hello </h1>
        View is {{view}}.
        </body></html>
        '''
    def __init__(self):
        pass

    def __call__(self,request,*args,**kwargs ):
        return HttpResponse(
        template.Template(self._t).render(template.RequestContext(request,{'view': str(args)})))

urlpatterns = patterns('',
    (r'^account/(.*)', Account()),
)

Filed under: Django

hdknr says...

登録/確認

^account/ ^signup/$
^account/ ^validate/$

ログイン/ログアウト

^account/ ^login/$
^account/ ^logout/$

パスワード操作

^account/ ^password_reset_key/(\w+)/$
^account/ ^password_change/$
^account/ ^password_set/$
^account/ ^password_delete/$
^account/ ^password_delete/done/$
^account/ ^password_reset/$

OpenID/RP

^account/ ^login/openid/$

プロファイル

^account/ ^email/$
^account/ ^confirm_email/(\w+)/$
^account/ ^timezone/$
^account/ ^language/$

サービス(Twitterとか)

^account/ ^other_services/$
^account/ ^other_services/remove/$

Filed under: Django

O Django é um framework para desenvolvimento web em python muito bem conceituado. Facilita o desenvolvimento web entre outras coisas que podem ser encontradas no site oficial do framework.
Estou usando ele para desenvolver um projeto relativamente grande, com muitas funcionalidades (atualmente em fase de desenvolvimento). Um dia desses tive que modificar o modelo de dados do sistema para adicionar mais um tipo de usuário. No inicio o sistema tinha apenas um tipo de perfil que era o de estudante, porém tive que adicionar o profile do professor no sistema. Quando um novo usuário vai entrar no sistema ele escolhe se é estudante ou professor, dependendo da escolha o sistema cria um tipo de profile diferente. Ai foi onde tive problema, pois o Django já é preparado para trabalhar com sistemas que utilizam profile, porém sistemas com apenas um profile (um tipo de usuário). Procurei bastante na internet sobre isso e acabei achando uma solução interessante, porém não me lembro mais qual foi o blog gringo que achei sobre isso (vou pesquisar e achando eu atualizo aqui). Adicionei este código no arquivo urls.py :

from django.contrib.auth.models import User

class UserGetProfileExtension:
    def _get_profile(self):
        if not hasattr(self, '_UserGetProfileExtension__cached_profile'):
            try:
                if hasattr(self, 'student'):
                    self.__cached_profile = self.student
                elif hasattr(self, 'professor'):
                    self.__cached_profile = self.professor
            except:
                self.__cached_profile = None
        else:
            self.__cached_profile = self._UserGetProfileExtension__cached_profile
        return self.__cached_profile
    profile = property(_get_profile)
User.__bases__ += ( UserGetProfileExtension, )

Agora para pegar o profile do usuário basta continuar usando:

user.profile

Espero que isso possa ajudar muita gente. Como as referências estão em inglês, este conteúdo em português é interessante. Até logo e depois vou colocando mais soluções interessantes.

Filed under: django