Re: Weird Django "caching" problem
Great! Thanks heaps for that. All fixed. On Jul 17, 3:04 am, Nan wrote: > If clearing your browser cache fixes it, then it's browser caching, > not Django caching. It's possible your PHP site was sending cache > suppression headers. If you want to prevent browser and proxy > caching, look into Django's never_cache decorator. > > On Jul 16, 9:51 am, Nathan Hoad wrote: > > > > > > > > > Hi guys, I migrated my site from PHP to Django about a fortnight ago > > and everything went really smoothly, except now there appears to be > > some kind of "caching" on certain pages. I say "caching" because I > > have no caching enabled in Django, and it seems to be browser based, > > i.e. I can open a page in any browser, three days later go back to the > > same page, and be presented with the old data. But if I force refresh > > or clear the cache for any of these browsers, then the new data > > appears (which is no good for typical users). The reason I think this > > problem has to do with Django is that it didn't happen at all with the > > old PHP site. > > > I've narrowed it down to being only the pages using a generic view, > > which made me think that the queryset is only being evaluated once. > > But then, as I said above, I can force refresh a page and see the new > > data, so this makes me think they're being evaluated more than once. > > > I'm pretty new to Django, so I don't fully know what I should do to > > try and remedy a problem like this. Any help or guidance would be > > great. Thanks guys. -- 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: auto_now, auto_now add -- good or bad?
On Sun, Jul 17, 2011 at 9:32 AM, Russell Keith-Magee wrote: > On Sat, Jul 16, 2011 at 12:22 AM, Shawn Milochik wrote: >> A discussion broke out in our office today about using these features, >> because there are blog posts[1] bashing them and a comment by JKM >> saying they should go away[2]. > > Heh. This is an argument that goes back quite some time. It's even > been captured on video (it's a long video, but I swear it's in there > somewhere) :-) > > [1] http://www.youtube.com/watch?v=tscMnoS4YU8 Curiosity got the better of me: It's at about 34:35. Russ %-) -- 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: auto_now, auto_now add -- good or bad?
On Sat, Jul 16, 2011 at 12:22 AM, Shawn Milochik wrote: > A discussion broke out in our office today about using these features, > because there are blog posts[1] bashing them and a comment by JKM > saying they should go away[2]. Heh. This is an argument that goes back quite some time. It's even been captured on video (it's a long video, but I swear it's in there somewhere) :-) [1] http://www.youtube.com/watch?v=tscMnoS4YU8 > It seems that all of the arguments against are based on the fact that > there were bugs in the past (links in the comments of the blog post > above). However, the "go away" comment is five years old and they're > still there, and the bug tickets have been patched. > > It's easy enough to do what these features do in a more explicit way. > > Considering these facts, I'm wondering what the consensus is in the community: > > A. They're still there because they're too annoying to deprecate > or just not important enough to spend time on. > > B. They're useful shortcuts and their use is preferable to manual > replacements. I know I'm in disagreement with Jacob here, but I'm in camp B. For me, the two most common use cases for a timestamp are a creation timestamp and an update timestamp, so it makes perfect sense that they are baked in as a top-level feature for timestamp model fields. I've used these flags extensively in production, and I'm not aware of any bugs that are actually problems in production. A *long* time ago, there were some issues with serialization, but I fixed those a long time ago because I was using timestamp flags. So - for me, it's not worth removing them. They serve a real-world common use case, they're not fundamentally broken as designed (as far as I am aware), and removing them would require a whole lot of pain in the wider community. Yours, Russ Magee %-) -- 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: Class-Based Generic Views (CreateView) - field exclusions and defaults
Hi Russ, Wow - your response is *exactly* what I needed - thanks a great deal :) As you mention in there, *because* CreateView gets me so far without the Form class (it builds me a form based on the model I declare), I was exactly looking to do other "ModelForm" stuff at the CreateView level. Now it is clear to me what I need to do. Thanks for your class-based generic views contribution, and I really hope someone will have the chance to do more docs and examples for class-based views. -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/XuIVKvgwZ-0J. 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: Weird Django "caching" problem
If clearing your browser cache fixes it, then it's browser caching, not Django caching. It's possible your PHP site was sending cache suppression headers. If you want to prevent browser and proxy caching, look into Django's never_cache decorator. On Jul 16, 9:51 am, Nathan Hoad wrote: > Hi guys, I migrated my site from PHP to Django about a fortnight ago > and everything went really smoothly, except now there appears to be > some kind of "caching" on certain pages. I say "caching" because I > have no caching enabled in Django, and it seems to be browser based, > i.e. I can open a page in any browser, three days later go back to the > same page, and be presented with the old data. But if I force refresh > or clear the cache for any of these browsers, then the new data > appears (which is no good for typical users). The reason I think this > problem has to do with Django is that it didn't happen at all with the > old PHP site. > > I've narrowed it down to being only the pages using a generic view, > which made me think that the queryset is only being evaluated once. > But then, as I said above, I can force refresh a page and see the new > data, so this makes me think they're being evaluated more than once. > > I'm pretty new to Django, so I don't fully know what I should do to > try and remedy a problem like this. Any help or guidance would be > great. Thanks guys. -- 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 form radio input layout
I found a snippet that does what I want.
http://djangosnippets.org/snippets/1377/
The documentation for it isn't great, and you have to edit it using
snippet 863 as a base.
His example does not work either but I got it to work like this
terms = ChoiceWithOtherField( choices = [ ('a','Until
Cancel', forms.RadioSelect),
('b','Until Date', forms.DateInput),
('c','Until Count', forms.TextInput)
] )
On Jul 16, 10:08 am, CrabbyPete wrote:
> Here is the closest snippet I found that works well for using 1 other
> field. I have 2 other fields and I guess I'll try to modify it. If you
> have any other snippets
> or suggestions please let me know.
>
> http://djangosnippets.org/snippets/863/
>
> On Jul 14, 3:56 pm, Bill Freeman wrote:
>
>
>
>
>
>
>
> > Unless things have changed, the trouble is that the individual bound fields
> > aren't all in existence at the same time, but are created and discarded
> > one at a time as the outer widget iterates the choices. I once uploaded
> > a snippet for a template tag that performed the iteration, allowing finer
> > styling control. I've forgotten the details, or the pointer to my snippet,
> > but such a tag could let you iterate template code for each button,
> > rendering
> > what you want, having recognized, say, the value of the button field that
> > you want to render differently in a template ifequal, or equivalent. Of
> > course
> > you are also then stuck with self rendering the whole Form, unless you put
> > everything else in one Form, and this in another, but all within the same
> > "form" tag so that they are submitted together. Your view needs to be aware
> > of the two forms. But at this point you could just separately render the
> > list
> > of choices by hand, leaving the Choice field out of the Form's fields list.
> > I
> > always put my choices lists as Model attributes, so I can make them easily
> > accessible in the template, though a suitable iterator method on the Model
> > makes the template code cleaner.
>
> > I'm liking the last approach best in that things like my template tag had to
> > dip into Field internals, so it is fragile across Django versions,
> > while rendering
> > the special radio collection by hand fits the "explicit is better than
> > implicit
> > (magic)" mantra, and doesn't use anything that is likely to change out from
> > under you. (Though adding a suitable iterator method on Choice/MultiChoice
> > Fields to the API would not be unwelcome.)
>
> > Bill
>
> > On Thu, Jul 14, 2011 at 3:10 PM, NateB wrote:
>
> > >CrabbyPetewrote:
>
> > >> I am trying to do the same thing. Did you ever get a response?
>
> > > I accepted an answer to the one on the stack overflow question I linked to
> > > in my previous email - however, it wasn't what I was *really* hoping for
> > > (although it definitely works). Before asking, I spent a long time
> > > searching through the Django code, and I couldn't come up with a clean
> > > solution (but figured that it was simply my ignorance, because I
> > > considered
> > > that a weird oversight). I get the impression now that there *is* no
> > > easy,
> > > pretty way of doing it, just a circuitous, not-so-pretty way of doing it.
> > > --
> > > View this message in
> > > context:http://old.nabble.com/django-form-radio-input-layout-tp31862033p32063...
> > > Sent from the django-users mailing list archive at Nabble.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
> > > athttp://groups.google.com/group/django-users?hl=en.
--
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 form radio input layout
Here is the closest snippet I found that works well for using 1 other field. I have 2 other fields and I guess I'll try to modify it. If you have any other snippets or suggestions please let me know. http://djangosnippets.org/snippets/863/ On Jul 14, 3:56 pm, Bill Freeman wrote: > Unless things have changed, the trouble is that the individual bound fields > aren't all in existence at the same time, but are created and discarded > one at a time as the outer widget iterates the choices. I once uploaded > a snippet for a template tag that performed the iteration, allowing finer > styling control. I've forgotten the details, or the pointer to my snippet, > but such a tag could let you iterate template code for each button, rendering > what you want, having recognized, say, the value of the button field that > you want to render differently in a template ifequal, or equivalent. Of > course > you are also then stuck with self rendering the whole Form, unless you put > everything else in one Form, and this in another, but all within the same > "form" tag so that they are submitted together. Your view needs to be aware > of the two forms. But at this point you could just separately render the list > of choices by hand, leaving the Choice field out of the Form's fields list. I > always put my choices lists as Model attributes, so I can make them easily > accessible in the template, though a suitable iterator method on the Model > makes the template code cleaner. > > I'm liking the last approach best in that things like my template tag had to > dip into Field internals, so it is fragile across Django versions, > while rendering > the special radio collection by hand fits the "explicit is better than > implicit > (magic)" mantra, and doesn't use anything that is likely to change out from > under you. (Though adding a suitable iterator method on Choice/MultiChoice > Fields to the API would not be unwelcome.) > > Bill > > > > > > > > On Thu, Jul 14, 2011 at 3:10 PM, NateB wrote: > > >CrabbyPetewrote: > > >> I am trying to do the same thing. Did you ever get a response? > > > I accepted an answer to the one on the stack overflow question I linked to > > in my previous email - however, it wasn't what I was *really* hoping for > > (although it definitely works). Before asking, I spent a long time > > searching through the Django code, and I couldn't come up with a clean > > solution (but figured that it was simply my ignorance, because I considered > > that a weird oversight). I get the impression now that there *is* no easy, > > pretty way of doing it, just a circuitous, not-so-pretty way of doing it. > > -- > > View this message in > > context:http://old.nabble.com/django-form-radio-input-layout-tp31862033p32063... > > Sent from the django-users mailing list archive at Nabble.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 > > athttp://groups.google.com/group/django-users?hl=en. -- 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.
Weird Django "caching" problem
Hi guys, I migrated my site from PHP to Django about a fortnight ago and everything went really smoothly, except now there appears to be some kind of "caching" on certain pages. I say "caching" because I have no caching enabled in Django, and it seems to be browser based, i.e. I can open a page in any browser, three days later go back to the same page, and be presented with the old data. But if I force refresh or clear the cache for any of these browsers, then the new data appears (which is no good for typical users). The reason I think this problem has to do with Django is that it didn't happen at all with the old PHP site. I've narrowed it down to being only the pages using a generic view, which made me think that the queryset is only being evaluated once. But then, as I said above, I can force refresh a page and see the new data, so this makes me think they're being evaluated more than once. I'm pretty new to Django, so I don't fully know what I should do to try and remedy a problem like this. Any help or guidance would be great. Thanks guys. -- 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: Error while customizing admin/change_form.html
Or simply add folder with same name of your app. For admin//.html -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/9Qe-eX2T5X8J. 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.
