Re: Dajax, what do you think about it?
I like it very much, it helps me a lot. I believe it's worthy of using it for every Django based project. On Sat, Apr 2, 2011 at 9:54 PM, Eric Hutchinson < eric.hutchin...@burgopakusa.com> wrote: > I don't see the advantage of writing your own ajax views. the examples > save maybe one, two lines over manually writing your own using plain > jquery. you still need to write javascript to submit the forms and > what not, so nothing is gained there. you still need to write a 'view' > only it's not quite a view, so you can't use the new class based > views, (check me on this i might be wrong) so that's a net loss. > > for myself at least, i'd rather have a good understanding of whats > going on in my app than to trust it to magic ajax url generation. > > On Mar 31, 12:55 am, Sameer Rahmani <lxsam...@gmail.com> wrote: > > What do you think about using Dajax and Dajaxice in Django? is it worth? > or > > you like to write your own ajax code? > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- === Regards Ronghui Yu -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Having trouble creating instances of another model in the __init__ of one model
The error in save, not in constructor, seems you need to set dome default
value to Team instances, not quite sure
On Sat, Feb 5, 2011 at 2:29 PM, Daniel Klein <bri...@gmail.com> wrote:
> I'm teaching myself django by idling poking at a project in the hope that
> it may become a playable browser game some day. It's early days.
>
> So I have a model "Game", which is one game session. Each game is supposed
> to have two teams. I doubt the content of the Team model matters very much,
> so I'll just paste the relevant bits from Game:
>
> class Game(models.Model):
>
> team1 = models.OneToOneField(Team, related_name="team1", null=True)
>
> team2 = models.OneToOneField(Team, related_name="team2", null=True)
>
>
>
> def __init__(self, *args, **kwargs):
>
> super(Game, self).__init__(self, *args, **kwargs)
>
> self.team1 = Team()
>
> self.team2 = Team()
>
>
> The code I used to have, which worked, manually created a game and its two
> teams. This was in the view for the "create new game" page, which I found
> all kinds of ugly. Since every game should start out with exactly two teams
> in it, it makes most sense to have that code inside the Game model, right?
>
> So here's the error I'm currently getting when I try to save a game:
>
> >>> from game.models import Team, Game
>
> >>> tg = Game(name="testgame")
>
> >>> tg.save()
>
> Traceback (most recent call last):
>
> File "", line 1, in
>
> File "c:\coding\django-1.1.1\django\db\models\base.py", line 410, in save
>
> self.save_base(force_insert=force_insert, force_update=force_update)
>
> File "c:\coding\django-1.1.1\django\db\models\base.py", line 470, in
> save_base
>
> manager.filter(pk=pk_val).extra(select={'a':
> 1}).values('a').order_by())):
>
> File "c:\coding\django-1.1.1\django\db\models\manager.py", line 129, in
> filter
>
> return self.get_query_set().filter(*args, **kwargs)
>
> File "c:\coding\django-1.1.1\django\db\models\query.py", line 498, in
> filter
>
> return self._filter_or_exclude(False, *args, **kwargs)
>
> File "c:\coding\django-1.1.1\django\db\models\query.py", line 516, in
> _filter_or_exclude
>
> clone.query.add_q(Q(*args, **kwargs))
>
> File "c:\coding\django-1.1.1\django\db\models\sql\query.py", line 1675,
> in add_q
>
> can_reuse=used_aliases)
>
> File "c:\coding\django-1.1.1\django\db\models\sql\query.py", line 1614,
> in add_filter
>
> connector)
>
> File "c:\coding\django-1.1.1\django\db\models\sql\where.py", line 56, in
> add
>
> obj, params = obj.process(lookup_type, value)
>
> File "c:\coding\django-1.1.1\django\db\models\sql\where.py", line 269, in
> process
>
> params = self.field.get_db_prep_lookup(lookup_type, value)
>
> File "c:\coding\django-1.1.1\django\db\models\fields\__init__.py", line
> 210, in get_db_prep_lookup
>
> return [self.get_db_prep_value(value)]
>
> File "c:\coding\django-1.1.1\django\db\models\fields\__init__.py", line
> 361, in get_db_prep_value
>
> return int(value)
>
> TypeError: int() argument must be a string or a number, not 'Game'
>
>
> I have no idea what this error means, and I strongly suspect I'm Doing It
> Wrong [tm] in the first place. There's probably a very easy way to do this
> that I'm not seeing.
>
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
--
===
Regards
Ronghui Yu
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Help on adding CSS to django project
It seems that you need to setup your web server to support static contents,
django has a middleware to do the job, but it is not recommended to use it
in product environment. I had this similar problem when I started to learn
django.
On Sat, Feb 5, 2011 at 6:15 AM, Chris Hannam <bassdr...@gmail.com> wrote:
> Apologies for that premature send:
>
>
>> Hi,
>> The way I have approached this is to have a static dir set in my urls.py:
>>
>
>>
> (r'^static/(?P.*)$', 'django.views.static.serve', {
> 'document_root': settings.MEDIA_ROOT }
> )
>
> settings.py has the following
> MEDIA_ROOT = os.path.join(PATH_SITE_ROOT, 'static')
> PATH_SITE_ROOT = os.path.normpath(os.path.dirname(__file__))
>
> I reference the css files in the html as /static/css/style.css etc
>
> The urls.py maps the url to the location on disk of the css files.
>
> Can you supply the error messages and some of your config if you are still
> having issues?
>
> CH
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
--
===
Regards
Ronghui Yu
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Best DRY practices for a view function that will be used by all other views.
To create a separate decorator, then all other view functions are decorated by this decorator. For implement this decorator, you don't need to include the login function, just redirect to login URL. Is that what you are asking for? On Sat, Feb 5, 2011 at 6:48 PM, Marc Aymerich <glicer...@gmail.com> wrote: > On Sat, Feb 5, 2011 at 9:21 AM, Ken Chida <ken.ch...@gmail.com> wrote: > > I tried my best to search for an answer but my efforts yielded nothing. > > Allow me to give you a simple example to illustrate my problem. Let's > > pretend that I want to have a login form on every single page on my > > website. Obviously, the login form will have a corresponding view > > function. What is the most elegant way to implement the login > functionality > > on every single page? One brute force method would be to include the > login > > view inside all view functions for every page; these view functions would > > call the login view if the HttpRequest object contains a flag that > becomes > > active when the user clicks the login submit button. This method would > > work, but it goes against DRY best practices. > > > > Is there a better way to do this? Maybe I can use a custom template tag? > > it sounds to me like you need a custom decorator for your views, I > can't give you more details since I've never written one. > > -- > Marc > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- === Regards Ronghui Yu -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Code Review As a Service
Wonderful idea Are you going to open business like that? On Tue, Jan 25, 2011 at 10:18 PM, Derek <gamesb...@gmail.com> wrote: > Yes, I think this is a great idea. > > Ideally, the charge-rate would be "per lines of code" (excluding > blanks, of course!). Hours are just, too, "amorphous" in this > particular case. > > On Jan 25, 11:42 am, Venkatraman S <venka...@gmail.com> wrote: > > Hi, > > > > I was wondering whether there any freelancers/companies who offer > > code-review as a service. > > IMHO, a code review helps in almost all occasions, but the faced paced > life > > seems to have > > put this in the back burner. > > > > Would like your code to be reviewed? If yes, what would be the ideal per > > hour rates that > > would not hurt your wallet? > > > > -Venkathttp://blizzardzblogs.blogspot.com/ > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- === Regards Ronghui Yu -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Register signal on all objects
How about creating a meta class for all your models in the project Matias ??: Is there any recommended way to attach a post_save signal to ALL models? The best way I'm thinking of is maybe by using the ContentType class to get a list of all models and iterate over them registering the signal, but I'm not sure if this is the best way to do it... Any comment appreciated... Thanks!! -- Ronghui Yu <mailto:stone...@163.com> -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: My first Django project
Hi, Kannan, I am very happy that you like this project. I knew nothing about Django before starting this project. I learnt a lot during this process. But for some reasons, there are still a few problems, I am doing my best to fix them. I would like to publish the code if there are many guys has interest in this project. But now, not the time. Thank you for your understanding. Kannan ??: > >The first project I do by using Django, http://www.cvcenter.cn > <http://www.cvcenter.cn/>, please take a >look, and enjoy. > >Any feedback will be appreciated. > > Hi friend... > I saw ur site.It is good. Congratulations for ur job. > Just i am started learning the Django.If u don't mind will u send the > project's souce code for my reference. > > > > With regards, > > Kannan. R. P, > > > > > > -- Ronghui Yu <mailto:stone...@163.com> --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: My first Django project
Thanks for your advice I'll think about it. :-) Mirat Bayrak ??: > Hi, i liked you project look slike simple cv center. May be you can > think about usability. For example creating items has too much steps. > May be you can put all that forms into one page. Or may be forms can > by dynamicaly shown above */create another foo item/* with jquery. In > other sides i liked it.. > > > -- Ronghui Yu <mailto:stone...@163.com> --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
My first Django project
The first project I do by using Django, http://www.cvcenter.cn, please take a look, and enjoy. Any feedback will be appreciated. Thanks a lot -- === Regards Ronghui Yu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Static content protection
My solution now is enclosing the file with a HttpResponse and then return. It is a bit slow.I wonder if we can create a Apache module(or module for other server) to authenticate access to specific file. I don't have experience on this. On Thu, Aug 6, 2009 at 11:59 AM, Dj Gilcrease <digitalx...@gmail.com> wrote: > > On Wed, Aug 5, 2009 at 7:28 PM, TheIvIaxx<theivi...@gmail.com> wrote: > > > > Hello, I have a question that probably spans a few different groups. > > However I know this setup is familiar withing the django community. > > > > I have apache handling all django/python stuff and have lighttpd > > handling the static content. All is well,works fine and fast. Auth > > is my problem on the static stuff. > > > > With django i can control auth with the built in auth middleware, > > however anyone can just type in a url to a static image and get it. > > Other than using directory auth on lighty or apache, how would you > > control access to the static content without having the user enter > > user/pass info every time them went to the site? > > > For protected static files I actually consider them non static and use > a model with a FileField to keep track of them, then a view to output > them that has the @login_required decorator. > > http://dpaste.com/75843/ > > you can even go so far as to create a tag library for it so it can be > used to display in files inline not just for download. > > This does make things a little slower then just having them served > directly, but if your site is for internal company use only the > slowdown will be non-significant in my experiance > > > > -- === Regards Ronghui Yu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Static content protection
I have the similar problem. Could not find a good way either. On Thu, Aug 6, 2009 at 9:28 AM, TheIvIaxx <theivi...@gmail.com> wrote: > > Hello, I have a question that probably spans a few different groups. > However I know this setup is familiar withing the django community. > > I have apache handling all django/python stuff and have lighttpd > handling the static content. All is well,works fine and fast. Auth > is my problem on the static stuff. > > With django i can control auth with the built in auth middleware, > however anyone can just type in a url to a static image and get it. > Other than using directory auth on lighty or apache, how would you > control access to the static content without having the user enter > user/pass info every time them went to the site? > > Thanks > > > -- === Regards Ronghui Yu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: 'str' object is not callable
Try to configure url from
(r'^(?P[-\w]+)/$', 'coltrane_category_detail'),
to
(r'^(?P[-\w]+)/$', coltrane_category_detail),
But before that, you need to import this function
Or
give a whole path to the view like
(r'^(?P[-\w]+)/$', 'pack_xxx.mod_xxx.coltrane_category_detail'),
On Mon, Aug 3, 2009 at 2:00 AM, Dolph <ekinsko...@gmail.com> wrote:
>
> hey guys,
>
> New to django and I'm just working through James Bennett's practical
> django projects book, 2nd ed. I'm trying to get the categories section
> working in the blog and I'm getting the above error. I've read through
> some of the previous posts to try to figure it out, but I can't seem
> to figure it out.
>
> error:
>
> /usr/lib/python2.5/site-packages/django/core/handlers/base.py in
> get_response, line 86
>
> categories.py in urls directory:
>
> from django.conf.urls.defaults import *
>
> from coltrane.models import Category
>
> urlpatterns = patterns('',
>(r'^$','django.views.generic.list_detail.object_list',
>{ 'queryset': Category.objects.all() }),
>(r'^(?P[-\w]+)/$', 'coltrane_category_detail'),
> )
>
> here's my view in coltrane:
>
> from django.shortcuts import get_object_or_404
> from coltrane.models import Category
> from django.views.generic.list_detail import object_list
>
> def category_detail(request, slug):
>category = get_object_or_404(Category, slug=slug)
>return object_list(request, queryset=category.entry_set.all(),
>extra_context={ 'category': category })
>
> the category list works ok and the get_absolute_url is rendering the
> correct link, but when I click on the link or attempt to get specific
> category details, i.e. "http://127.0.0.1:8000/weblog/categories/
> programming/", I get the above error.
>
> thanks.
>
> Eric
>
> >
>
--
===
Regards
Ronghui Yu
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: which version of django should I choose?
In my opinion, every version is good for learning. Just try it. And if you encounter difficuties for upgrading to another one, you will learn a lot from it. XUN ZHOU 写道: > hello, I am new beginner in django. I want to learn python with django > and later I want to write my first application in google App engine. > there are so many different version of django. > which version should I beginn? thanks your help or advice > > -- > Xun Zhou > TU Berlin > > > -- Ronghui Yu <mailto:stone...@163.com> --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: django-registration and RegistrationFormUniqueEmail subclass
You don't need to implement one, it is there in registration/forms.py
What you need to do is configure you url like this
url(r'^register/$',
register,
{'form_class':RegistrationFormUniqueEmail},
name='registration_register'),
Before that, you need to import RegistrationFormUniqueEmail
from registration.forms import RegistrationFormUniqueEmail
Léon Dignòn ??:
> Hey folks,
>
> I don't know how to implement the RegistrationFormUniqueEmail
> subclass.
>
> I have a new project and installed django-registration. I got some
> templates wich work well. Now I want, that E-Mail addresses are
> unique. For that in the forms-documentation is mentioned, that there
> is a subclass called RegistrationFormUniqueEmail.
>
> But I don't have any idea what to do with this information. I am no
> Django guru :(
>
> Could you hellp me with that?
> >
>
>
--
Ronghui Yu <mailto:stone...@163.com>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: never_cache doesn't work for login page
Eugene Mirotin ??: > May be the order of middleware classes does matter here? > > On Jul 19, 4:08 pm, Ronghui Yu <stone...@gmail.com> wrote: > >> It proves that it is introduced by >> django.middleware.http.ConditionalGetMiddleware. It returns 304 when >> requesting the same login page, so at last the browser uses the former one. >> It works fine after removing this middleware. >> I believe this middleware cannot work with never_cache. >> >> Eugene Mirotin ??: >> >> >> >> >>> Isn't adding a timestamp to the url a workaround? >>> I mean making all links to /login/ look like /login/?_=timestamp >>> This can be easily done on the client side with some JS library, or, >>> on the server side. >>> >>> Not nice, but it should help, I guess. >>> >>> On Jul 17, 5:24 pm, Ronghui Yu <stone...@gmail.com> wrote: >>> >>>> Hi, All, >>>> >>>> I have a project that have CsrfMiddleware enable, all forms work fine, >>>> but the login form doesn't, for all browsers(IE,Chrome,Firefox,Safari). >>>> Most of the time, it throws 403, which is thrown by CsrfMiddleware. >>>> That's because the browser cache the login page, so each time the login >>>> page is opened, the csrfmiddlearetoken value doesn't get update. If the >>>> browser cache is cleaned before opening the login page, then it works >>>> fine. But this is not what I expect. >>>> >>>> When look into django.contrib.auth.views, the login view is decorated by >>>> never_cache, but actually it doesn't work for me. I have no idea what's >>>> wrong with it. Has anybody ever encounted this situation? Or could >>>> anybody give me some hints? >>>> >>>> Thanks in advance. >>>> >>>> -- >>>> Ronghui Yu <mailto:stone...@163.com> >>>> >> -- >> Ronghui Yu <mailto:stone...@163.com> >> I had tried to reorder the middlewares, but it didn't work either. Here is the comment of ConditionalGetMiddleware: 5 Handles conditional GET operations. If the response has a ETag or 6 Last-Modified header, and the request has If-None-Match or 7 If-Modified-Since, the response is replaced by an HttpNotModified. 8 9 Also sets the Date and Content-Length response-headers. I think the login page falls into this scope even it is decorated by never_cache. -- Ronghui Yu <mailto:stone...@163.com> --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: looking for a clean, easy way to force user to change password on first login
How about writing a decorator? pjv ??: > thanks again. writing that login view is what i meant by re- > implementing the login. my terminology is probably confusing. there is > a generic login view in django.contrib.auth.views that does what you > are saying, only [obviously] without the custom redirect logic that i > want. i just copied and pasted that view into my own view and modified > the 'standard' redirect logic in it to include the test for the two > passwords being the same. but replacing the generic view was what i > was originally hoping to avoid in case it gets me out of sync with > future django updates on how auth/login works. > > but it's probably fine, and it is currently giving me the behavior > that i want. > > On Jul 18, 9:13 pm, Shawn Milochik <shawn.m...@gmail.com> wrote: > >> If I understand correctly, you can do this without having to re- >> implementing the login. You will have to make a (very simple) login >> template, and write a login view that contains these: >> >> from django.contrib.auth import login >> login(request, form.get_user()) >> >> Then you can handle the redirection however you like. >> > > > > -- Ronghui Yu <mailto:stone...@163.com> --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: never_cache doesn't work for login page
It proves that it is introduced by django.middleware.http.ConditionalGetMiddleware. It returns 304 when requesting the same login page, so at last the browser uses the former one. It works fine after removing this middleware. I believe this middleware cannot work with never_cache. Eugene Mirotin ??: > Isn't adding a timestamp to the url a workaround? > I mean making all links to /login/ look like /login/?_=timestamp > This can be easily done on the client side with some JS library, or, > on the server side. > > Not nice, but it should help, I guess. > > On Jul 17, 5:24 pm, Ronghui Yu <stone...@gmail.com> wrote: > >> Hi, All, >> >> I have a project that have CsrfMiddleware enable, all forms work fine, >> but the login form doesn't, for all browsers(IE,Chrome,Firefox,Safari). >> Most of the time, it throws 403, which is thrown by CsrfMiddleware. >> That's because the browser cache the login page, so each time the login >> page is opened, the csrfmiddlearetoken value doesn't get update. If the >> browser cache is cleaned before opening the login page, then it works >> fine. But this is not what I expect. >> >> When look into django.contrib.auth.views, the login view is decorated by >> never_cache, but actually it doesn't work for me. I have no idea what's >> wrong with it. Has anybody ever encounted this situation? Or could >> anybody give me some hints? >> >> Thanks in advance. >> >> -- >> Ronghui Yu <mailto:stone...@163.com> >> > > > > -- Ronghui Yu <mailto:stone...@163.com> --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: never_cache doesn't work for login page
That's a good idea. I'll make it the last resort if I can't figure out a better way to handle it. Thank you Eugene Mirotin ??: > Isn't adding a timestamp to the url a workaround? > I mean making all links to /login/ look like /login/?_=timestamp > This can be easily done on the client side with some JS library, or, > on the server side. > > Not nice, but it should help, I guess. > > On Jul 17, 5:24 pm, Ronghui Yu <stone...@gmail.com> wrote: > >> Hi, All, >> >> I have a project that have CsrfMiddleware enable, all forms work fine, >> but the login form doesn't, for all browsers(IE,Chrome,Firefox,Safari). >> Most of the time, it throws 403, which is thrown by CsrfMiddleware. >> That's because the browser cache the login page, so each time the login >> page is opened, the csrfmiddlearetoken value doesn't get update. If the >> browser cache is cleaned before opening the login page, then it works >> fine. But this is not what I expect. >> >> When look into django.contrib.auth.views, the login view is decorated by >> never_cache, but actually it doesn't work for me. I have no idea what's >> wrong with it. Has anybody ever encounted this situation? Or could >> anybody give me some hints? >> >> Thanks in advance. >> >> -- >> Ronghui Yu <mailto:stone...@163.com> >> > > > > -- Ronghui Yu <mailto:stone...@163.com> --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: never_cache doesn't work for login page
Michael 写道: > On Fri, Jul 17, 2009 at 11:19 AM, Ronghui Yu <stone...@gmail.com > <mailto:stone...@gmail.com>> wrote: > > > > Michael 写道: >> 2009/7/17 Ronghui Yu <stone...@gmail.com <mailto:stone...@gmail.com>> >> >> Hi, All, >> >> I have a project that have CsrfMiddleware enable, all forms >> work fine, but the login form doesn't, for all >> browsers(IE,Chrome,Firefox,Safari). >> Most of the time, it throws 403, which is thrown by >> CsrfMiddleware. That's because the browser cache the login >> page, so each time the login page is opened, the >> csrfmiddlearetoken value doesn't get update. If the browser >> cache is cleaned before opening the login page, then it works >> fine. But this is not what I expect. >> >> When look into django.contrib.auth.views, the login view is >> decorated by never_cache, but actually it doesn't work for >> me. I have no idea what's wrong with it. Has anybody ever >> encounted this situation? Or could anybody give me some hints? >> >> Thanks in advance. >> >> -- >> Ronghui Yu <mailto:stone...@163.com> >> >> >> I have encountered this, but it isn't a problem with the admin, >> it is a problem with the browser. These pages are stored for >> offline use and then when the user goes to the page, they don't >> get a new token. You can see here [1] and here [2] where the >> views are cached. You can look at your browser and see that the >> headers are right as well. You should see something along these >> lines in the headers: Cache-Control max-age=0 >> >> 1] >> >> http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/sites.py#L324 >> 2] >> http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/sites.py#L188 >> >> I haven't been able to figure out how to fix this behavior in the >> browser, but the user only needs to refresh a few times to break >> that cache. >> >> I would love to hear if anyone else has figured something out to >> fix this. >> >> Also if you are using the 1.1 branch, make sure you update svn >> there was a recent fix put in for caching of all pages[3], but >> otherwise, the best I can tell, this is a browser issue, and not >> something Django can easily fix. >> >> 3] http://code.djangoproject.com/ticket/11416 >> >> I hope that helps, >> >> Michael >> >> > Thanks Michael. > > Look into the apache log, I see that when the login page is > accessed again, it returns 304, then the subsequent submit returns > 403. > > 116.22.69.90 - - [17/Jul/2009:23:12:06 +0800] "GET > /accounts/login/ HTTP/1.0" 304 > 116.22.69.90 - - [17/Jul/2009:23:12:17 +0800] "POST > /accounts/login/ HTTP/1.0" 403 159 > > I guess there are some tags that apache or mod_python omits. But I > am not sure. I will do more research soon. > > > -- > Ronghui Yu <mailto:stone...@163.com> > > > Hmm, interesting, What do your HTTP headers look like? > I couldn't find a way to view all request headers in access log. How did you do that, Michael? Or you have another way? I would try to get it by setting DEBUG=True, but when it is set, login page always works fine. -- Ronghui Yu <mailto:stone...@163.com> --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: never_cache doesn't work for login page
Michael ??: > 2009/7/17 Ronghui Yu <stone...@gmail.com <mailto:stone...@gmail.com>> > > Hi, All, > > I have a project that have CsrfMiddleware enable, all forms work > fine, but the login form doesn't, for all > browsers(IE,Chrome,Firefox,Safari). > Most of the time, it throws 403, which is thrown by > CsrfMiddleware. That's because the browser cache the login page, > so each time the login page is opened, the csrfmiddlearetoken > value doesn't get update. If the browser cache is cleaned before > opening the login page, then it works fine. But this is not what I > expect. > > When look into django.contrib.auth.views, the login view is > decorated by never_cache, but actually it doesn't work for me. I > have no idea what's wrong with it. Has anybody ever encounted this > situation? Or could anybody give me some hints? > > Thanks in advance. > > -- > Ronghui Yu <mailto:stone...@163.com> > > > I have encountered this, but it isn't a problem with the admin, it is > a problem with the browser. These pages are stored for offline use and > then when the user goes to the page, they don't get a new token. You > can see here [1] and here [2] where the views are cached. You can look > at your browser and see that the headers are right as well. You should > see something along these lines in the headers: Cache-Control max-age=0 > > 1] > http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/sites.py#L324 > 2] > http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/sites.py#L188 > > I haven't been able to figure out how to fix this behavior in the > browser, but the user only needs to refresh a few times to break that > cache. > > I would love to hear if anyone else has figured something out to fix > this. > > Also if you are using the 1.1 branch, make sure you update svn there > was a recent fix put in for caching of all pages[3], but otherwise, > the best I can tell, this is a browser issue, and not something Django > can easily fix. > > 3] http://code.djangoproject.com/ticket/11416 > > I hope that helps, > > Michael > > Thanks Michael. Look into the apache log, I see that when the login page is accessed again, it returns 304, then the subsequent submit returns 403. 116.22.69.90 - - [17/Jul/2009:23:12:06 +0800] "GET /accounts/login/ HTTP/1.0" 304 116.22.69.90 - - [17/Jul/2009:23:12:17 +0800] "POST /accounts/login/ HTTP/1.0" 403 159 I guess there are some tags that apache or mod_python omits. But I am not sure. I will do more research soon. -- Ronghui Yu <mailto:stone...@163.com> --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
never_cache doesn't work for login page
Hi, All, I have a project that have CsrfMiddleware enable, all forms work fine, but the login form doesn't, for all browsers(IE,Chrome,Firefox,Safari). Most of the time, it throws 403, which is thrown by CsrfMiddleware. That's because the browser cache the login page, so each time the login page is opened, the csrfmiddlearetoken value doesn't get update. If the browser cache is cleaned before opening the login page, then it works fine. But this is not what I expect. When look into django.contrib.auth.views, the login view is decorated by never_cache, but actually it doesn't work for me. I have no idea what's wrong with it. Has anybody ever encounted this situation? Or could anybody give me some hints? Thanks in advance. -- Ronghui Yu <mailto:stone...@163.com> --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Global custom tags
_init_.py should be __init__.py or just a typo error in the mail? diogobaeder ??: > Koen, > > I tried to make an initial template tag, just to test and learn, but > it's not working. I followed the instructions here > http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#howto-custom-template-tags > and registered the compilation function, but it's not finding the > module, like stated here in this stack trace, even though I've saved > the _init_.py file: > http://dpaste.com/63306/ > > The code I used to test it is here: > http://dpaste.com/63308/ > > Any ideas? > > Thanks again! > > Diogo > > > > On Jul 3, 3:10 am, koenb <koen.bierm...@werk.belgie.be> wrote: > >> On 3 jul, 04:59, diogobaeder <diogobae...@gmail.com> wrote: >> >> >>> But where do I put the custom template, than? If I load it from an app >>> template, I must create it under /templatetags/, and what if I >>> want to call it from the base template? /templatetags/? >>> >>> Thanks! >>> >>> Diogo >>> >> I think you are missing something here: there really is no app >> namespacing in templatetags: if you try to load a tag library, django >> will search the templatetags folders located underneath all installed >> apps. If it finds one that matches, it will use that one. This means >> that you can use a tag library from app X in any template you use (no >> matter where it is located), as long as app X is in the installed >> apps. The downside of this is that you need to name your tag libraries >> wisely, because tags.py in app X and tags.py in app Y will conflict. >> >> Koen >> > > > > -- Ronghui Yu <mailto:stone...@163.com> --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Easy way to include Request Context always?
I had the same problem. I didn't find a built-in way to solve this. But I think you can implement a custom render_to_response, which calls the built-in one in turn. Then what you need to do is just importing your custome one. Streamweaver ??: > I'm still struggling a bit with template contexts > > What I want to do is put a code snippet in the header of my site base > template that either presents the user with a small login form if they > aren't authenticated or display a "Welcome! user" where user is linked > to their profile. > > It seems I have to pass RequestContext(request) everytime I call > render_to_response but I'm sure there's an easier way I'm missing. > I've read through the docs and apologize if I'm missing it but can > someone help with some advice? > > Thanks in advance. > > > > -- Ronghui Yu <mailto:stone...@163.com> --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Flatpages only works when settings.DEBUG = True
It works now. That's because a typo error happens in my 404.html page. And it introduces 500.Thanks all. On Tue, May 5, 2009 at 9:17 AM, Ronghui Yu <stone...@gmail.com> wrote: > Yes, 404.html and 500.html are there. But they extend from base.html, which > depends on some context variables. I will change them to a simple one and > see if the problem still there.Thanks > > > On Tue, May 5, 2009 at 12:06 AM, Brian Neal <bgn...@gmail.com> wrote: > >> >> On May 4, 10:28 am, Ronghui Yu <stone...@gmail.com> wrote: >> > Hi,All, >> > >> > I am going to use Flatpages app for those simple pages. And everything >> > works fine when settings.DEBUG is True, but when it is turned to False, >> > a URL not configured in urlpatterns will trigger 500, not 404. >> >> Do you have a 404.html error template? You need to have that before >> flatpages will work when DEBUG is False. See the note titled "Ensure >> that your 404 template works" in this section: >> >> >> http://docs.djangoproject.com/en/dev/ref/contrib/flatpages/#module-django.contrib.flatpages >> >> Its also a good idea to have a 500.html error template. >> >> Best, >> BN >> >> >> >> >> > > > -- > === > Regards > Ronghui Yu > -- === Regards Ronghui Yu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Flatpages only works when settings.DEBUG = True
Yes, 404.html and 500.html are there. But they extend from base.html, which depends on some context variables. I will change them to a simple one and see if the problem still there.Thanks On Tue, May 5, 2009 at 12:06 AM, Brian Neal <bgn...@gmail.com> wrote: > > On May 4, 10:28 am, Ronghui Yu <stone...@gmail.com> wrote: > > Hi,All, > > > > I am going to use Flatpages app for those simple pages. And everything > > works fine when settings.DEBUG is True, but when it is turned to False, > > a URL not configured in urlpatterns will trigger 500, not 404. > > Do you have a 404.html error template? You need to have that before > flatpages will work when DEBUG is False. See the note titled "Ensure > that your 404 template works" in this section: > > > http://docs.djangoproject.com/en/dev/ref/contrib/flatpages/#module-django.contrib.flatpages > > Its also a good idea to have a 500.html error template. > > Best, > BN > > > > > -- === Regards Ronghui Yu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Flatpages only works when settings.DEBUG = True
That's something I didn't try. It is a good idea to figure out what the problem is.Thanks On Tue, May 5, 2009 at 12:01 AM, Masklinn <maskl...@masklinn.net> wrote: > > On 4 May 2009, at 17:28 , Ronghui Yu wrote: > > I don't quite understand why this happens, and how to solve it. > > Has anybody ever met this problem? And any suggestions? > > > > Thanks in advance. > > > Setup a local smtp sink and activate the "mail on 500" thing, to see > why it's erroring out? > > > > -- === Regards Ronghui Yu --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Flatpages only works when settings.DEBUG = True
Hi,All, I am going to use Flatpages app for those simple pages. And everything works fine when settings.DEBUG is True, but when it is turned to False, a URL not configured in urlpatterns will trigger 500, not 404. This happens on both Apache2 and the Django native testing server. Here is some outputs from ./manage.py runserver [04/May/2009 23:21:24] "GET /cases/ HTTP/1.1" 500 10947 [04/May/2009 23:21:25] "GET /cases/css/css.css HTTP/1.1" 500 10947 [04/May/2009 23:21:26] "GET /cases/images/bj.gif HTTP/1.1" 500 10947 [04/May/2009 23:21:26] "GET /cases/images/logo.gif HTTP/1.1" 500 10947 [04/May/2009 23:21:27] "GET /cases/images/name.gif HTTP/1.1" 500 10947 [04/May/2009 23:21:27] "GET /cases/images/icon.gif HTTP/1.1" 500 10947 /cases/ is one of the flatpage url in the database. I don't quite understand why this happens, and how to solve it. Has anybody ever met this problem? And any suggestions? Thanks in advance. -- Ronghui Yu <mailto:stone...@163.com> --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
