How to get to initial value in admin fieldset?
I'm trying to customize admin template fieldset.html and I need to
show field's value without widget. The loop there is: for line in
fieldset | for field in line. The widget is shown like this:
field.field. I tried field.initial, and various combinations; the only
way I found to show dictionary of form values is:
field.field.form.initial . But I need the value of that particular
field. How can I do this?
Also: how can I do something similar to {{ dir(field) }} ? It would be
extremely helpful because it can be very hard to track down the
properties / methods of whatever object is passed to the template in
django code. 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-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.
Combined search of specific fields
The following code works fine but I'm wondering if there's a better /
clearer way to do this. `qw` is a list of words to search for,
`exclude` is a list of words to exclude from search. Thanks!
"""
Search records based on query and checkboxes checked in
the search form. Query can have words with minus in front
(e.g.: -word) to exclude
terms. There are three checkboxes, titles, problems and
solutions; any combination
can be checked. Respective field in db table is searched
when checkbox for it is
checked.
"""
# perform search
r = Solution.objects.all()
queries = {}
for word in qw + exclude:
queries[word] = []
if titles == "on":
for word in qw + exclude:
queries[word].append(Q(title__icontains=word))
if solutions == "on":
for word in qw + exclude:
queries[word].append(Q(solution__icontains=word))
# if nothing is checked (or problems), search problems
# note that we're implicitly using last word created by
code above, because There
# number of types of search checked will be the same for
all words.
if problems == "on" or not queries[word]:
for word in qw + exclude:
queries[word].append(Q(problem__icontains=word))
if len(queries[word]) == 3:
for w in qw: r = r.filter(queries[w][0] | queries[w]
[1] | queries[w][2])
for w in exclude: r = r.exclude(queries[w][0] |
queries[w][1] | queries[w][2])
if len(queries[word]) == 2:
for w in qw: r = r.filter(queries[w][0] | queries[w]
[1])
for w in exclude: r = r.exclude(queries[w][0] |
queries[w][1])
else:
for w in qw: r = r.filter(queries[w][0])
for w in exclude: r = r.exclude(queries[w][0])
--
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: Combined search of specific fields
Doh, here it is with hopefully fixed formatting:
""" The following code searches records based on query and
checkboxes checked in the search form. Query can have
words
with minus in front (e.g.: -word) to exclude terms. There
are
three checkboxes, titles, problems and solutions; any
combination can be checked. Respective field in db table
is
searched when checkbox for it is checked. """
# perform search
r = Solution.objects.all()
queries = {}
for word in qw + exclude:
queries[word] = []
if titles == "on":
for word in qw + exclude:
queries[word].append(Q(title__icontains=word))
if solutions == "on":
for word in qw + exclude:
queries[word].append(Q(solution__icontains=word))
# if nothing is checked (or problems), search problems
# note that we're implicitly using last word created by
code
# above, because the number of types of search checked
will
# be the same for all words.
if problems == "on" or not queries[word]:
for word in qw + exclude:
queries[word].append(Q(problem__icontains=word))
if len(queries[word]) == 3:
for w in qw: r = r.filter(
queries[w][0] | queries[w][1] | queries[w][2])
for w in exclude: r = r.exclude(
queries[w][0] | queries[w][1] | queries[w][2])
if len(queries[word]) == 2:
for w in qw: r = r.filter(
queries[w][0] | queries[w][1])
for w in exclude: r = r.exclude(
queries[w][0] | queries[w][1])
else:
for w in qw: r = r.filter(queries[w][0])
for w in exclude: r = r.exclude(queries[w][0])
--
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.
New Django tutorial
Hi, I plan to make a bunch of Django tutorials and I just finished the first one: http://lightbird.net/dbe/ Please let me know how it can be improved and I'll incorporate suggestions into upcoming tutorials. Thanks! -ak -- 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: New Django tutorial
Thanks for great feedback, Euan. I've added some comments below. On Jul 3, 8:26 am, "euan.godd...@googlemail.com" wrote: > I had a look over your tutorial and it looks pretty sweet. Definitely > gets down into explaining how to use the admin interface and taught me > things I hadn't realized. I have a few suggestions for you (feel free > to ignore :)): > > 1) I'm not sure how good an idea it is to call the attribute on your > DateTime model "datetime" - it conflicts with the datetime module. > Although this shouldn't cause any problems, it might be confusing. Hm, maybe calling it 'created' is better.. but then you'll have created.created which also doesn't look that great. I generally avoid using names like list, tuple because they're built-ins and also because they get highlighted in Vim :). Haven't really thought about using module names.. In fact I don't think I ever ran into this before. I'll have to think about this! > > 2) In the "Changing Save Redirect" section you import a load of stuff > inside an instance method. I'd prefer to see this imported at module > level. I agree, that's what I do when I do actual development; but in this case I made an exception to keep the tutorial shorter. Generally my idea for this set of tutorials is to err on the side of maintaining momentum rather than doing things by the book, I'll expand on this idea more below. > 3) In the same section, you do request.POST.has_key. I believe the > preferred syntax is "name_of_key" in request.POST. That's straight from Django sources :). > 4) In the same section you are using hard-coded URLs - can you not get > these by using reverse() ? It might not be possible as I know the I want to introduce reverse() a bit later, in a larger tutorial where it will be more self-evidently useful. So, the goal is to have someone who's not a programmer go through the tutorial and feel that a useful and practical app was done with very little code and only explain enough concepts that are necessary for that particular app. Then, over the course of the whole set of tutorials, various concepts will be introduced at the exact point when they'd be most useful. On the other hand, I haven't actually used reverse() myself. I know that it can get a little tricky. I'll definitely try to see if it makes sense to introduce it in the view function. > admin is quite a beast. > 5) In the mark_done method on Item, you could definitely use reverse > and that should aid any changes to your URL structure. > 6) In the "Customizing DateTime" your unicode method returns a str not > unicode Good point - will fix that. > 7) In the same section you talk about an OnOff property. I think you > actually mean attribute (although in terms of the concept it is indeed > a property, just in terms of the model it is an attribute) Yes, that's where I have to balance use of language that sounds clearer vs. fine points of terminology. I feel that most programming tutorials are too quick to emphasize correct terminology, but I definitely get where that comes from, too.. > 8) In the "Adding users" section, I think you could replace the loop > with: > > Item.objects.filter(created=obj, > user_isnull=True).update(user=request.user). Good, this is actually new to me. I'll keep it in mind but I think for the first tutorial the loop is clearer and this is something that should be introduced when performance gain will be more apparent. > > This would use only one SQL UPDATE and not n SELECTs and n UPDATEs. > > 9) At the end when the possible actions are checked it might be nice > to raise an exception if you don't find a valid action. Here, in fact, I'm following Django tutorial where they at one point rely on the regex in urls.py and then explain that they're not validating because it would not get through the regex if it were wrong. On the other hand, depending on the project, I might raise an exception if I feel that an error in the regex might be hard to debug otherwise. > > I hope you find the above helpful. There's very little wrong with the > tutorial and it's really clear, but I think at least some of the > points might be well incorporated. Very helpful - even if I didn't follow all of the advice, just thinking and going through the reasons was extremely valuable. I really appreciated the detailed critique, and I'd be very thankful if you also looked at my future tutorials I'll also post here. -ak -- 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.
New tutorial added to Django by Example
I've added a new tutorial: A simple Blog to my Django by Example site. As always, feedback is appreciated. This tutorial covers display of monthly archive, pagination, a simple, basic comment system, notification when comments are posted and a flexible interface for deletion of spammy comments. Hope you enjoy it! -ak -- 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: New tutorial added to Django by Example
Oh! I forgot the URL: http://lightbird.net/dbe/ -- 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: New tutorial added to Django by Example
Thanks for great comments, Euan. See a few notes below..
On Jul 7, 6:20 am, "euan.godd...@googlemail.com"
wrote:
> Hi again,
>
> I've had a read over your blog tutorial and have the following
> suggestions:
>
> 1) Make it PEP-8 (http://www.python.org/dev/peps/pep-0008/) compliant
> - it's a lot easier to read.
I fixed some things, I'm a bit ambivalent about 79 char limit. I feel
that with monitors getting larger, I think a lot of people use wider
windows, even if you have two 100-char windows side by side, you'll
still have some space left on many monitors. And there's a lot less
wrapping going from 79 to 99.
I also think code like:
if: ..
else: ..
..
looks more readable in most cases (depending on how long the clauses
are), than:
if:
..
else:
..
..
In other words, I always try to add a line after this type of
construct. (I know I missed it in a few places in current tutorial.)
> 2) Except only the error that might occur in the paginatior example.
> Bare excepts are BAD.
True, will fix.
> 3) Maybe consider enabling the context processor that adds the current
> user to the context
That's something I haven't done before so I'm not sure how to do it.
> 4) Consider using @login_required since all your views will break for
> logged out users
Hmm, all views work fine for me when logged out..
> 5) Consider using {% url %} instead of hard-coding your URLs
I'm running into problems with this tag in some cases. For example, in
admin's template, if I say {% url dbe.blog %} or just {% blog %}, or
add '.urls' to either, it's unable to reverse and throws an error. The
same thing happens when I try to do {% blog.urls post.id %} for the
"comments" link that goes on front page. I haven't used reverse before
so I might be missing something here.. In all other links in this
tutorial, reverse works fine.
> 6) It isn't necessary to coerce the pk to an int as Django takes care
> of it in: Post.objects.get(pk=int(pk))
Thanks! will fix..
> 7) I think the naming of variables in the add_comment view are
> confusing. The comment object is given a single letter name "c", but
> the comment form is confusingly given the name "comment". I'd suggest
> using more descriptive names,
Actually comment form is called cf, and on save it returns comment
object. But you're right, it shouldn't be called 'c' at first, will
fix..
> 8) In the same section you assume that the POST data will always have
> the key. Either use form validation here or allow for the POST to have
> missing data.
True, will fix.
> 9) The mkmonth_list could largely be taken care of by the builtin
> calendar module
I don't see how this function can be simplified with calendar. I'm
pretty familiar with it, I used it in a few projects recently.
Calendar is mostly helpful for days / weeks.
>
> Hope you find this helpful.
Very much so! Keep 'em coming!
>
> Euan
--
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: New tutorial added to Django by Example
On Jul 9, 9:41 pm, John M wrote: > WOW, this is very cool, you should see if you can add it to the main > django tutorial someway? Thanks! I don't think it will be added to main tutorial but I added the link to the list of tutorials on Django Wiki. -ak -- 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.
New tutorial added to Django by Example
I've added a new tutorial: A Photo Organizer and Sharing App to my Django by Example site. As always, feedback is appreciated. This tutorial illustrates the use of tags, ratings, albums, sharing, searching, filtering and sorting. http://LightBird.net/dbe/ -ak -- 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.
New tutorial added to Django by Example
I've added a new tutorial: A Simple Forum to my Django by Example site. As always, feedback is appreciated. http://LightBird.net/dbe/ -ak -- 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: New tutorial added to Django by Example
On Jul 19, 1:49 pm, Venkatraman S wrote: > On Mon, Jul 19, 2010 at 11:06 PM, Rainy wrote: > > I've added a new tutorial: A Simple Forum to my Django by Example > > site. As always, feedback is appreciated. > > > http://LightBird.net/dbe/ > > You rock ;) > A small nit : make the site more search-friendly. Probably, add a few > keywords/description etc? Thanks! Do you mean, to every page? That might be a bit hard, I'm using Sphinx for site generation, I'm not sure it can do a different head section for each page... -ak > > -Vhttp://theindianstreet.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-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: New tutorial added to Django by Example
On Jul 19, 2:33 pm, Venkatraman S wrote: > On Mon, Jul 19, 2010 at 11:46 PM, Rainy wrote: > > > > http://LightBird.net/dbe/ > > > > You rock ;) > > > A small nit : make the site more search-friendly. Probably, add a few > > > keywords/description etc? > > > Thanks! Do you mean, to every page? That might > > be a bit hard, I'm using Sphinx for site generation, > > I'm not sure it can do a different head section > > for each page... -ak > > Am not exactly sure how these SEO works. But i guess having a > keyword/description in the meta tag(header) would be good enough. Others can > chip in with their knowledge :) I think the things in meta tags in head section don't matter much. It's mostly about actual content of the page because google wants to rely on what visitors see on the page. -ak -- 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: New tutorial added to Django by Example
On Jul 20, 12:09 pm, Mitch wrote: > For SEO, your title tags matter greatly, as do the tags, page > content and link text into and within the pages, probably in that > order. If I were you, I'd make sure each page's and tag > had "Django tutorial" in it. For example, on the "Todo List App" page > I'd change the title to something like "Django 1.2 Tutorial: Todo List > App", and the same for the tag. Adding your site name in the > title and h1 isn't nearly as important. You already rank well for the > search "Django by example" and (without checking the Google searches) > I'm guessing that search phrase is much smaller than "django > tutorials". > > Thanks for making your tutorial site. I just did a short blog post > about it (http://mitchfournier.com/2010/07/20/django-1-2-tutorials- > django-by-example/) to get you a few more inlinks. Thanks for doing the blog post; I will change these tags as you recommend. I only started Django by example a couple of weeks ago so I'm sure soon more sites will link to it and it will show up better on google. -ak -- 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: Best way to present N items in table row for list
On Jul 27, 12:51 pm, Wadim wrote: > Hello. > I have a list that i want to present in a table. > Each row should have 5 items. > For now i create the function that returns me new grouped list, that i > use later in a template. > def groupListByRow(list): > cnt=0 > rows=[] > while cnt row=[] > for x in range(5): > if cnt row.append(list[cnt]) > else: > row.append(None) > cnt+=1 > rows.append(row) > return rows; > is there better way to do this? May be it is possible to do it inside > template? > Thanks Are you sure you need a table and you can't just make a bunch of floating DIVs with some fixed width? If you need a table, I would personally prefer to do this in python code, like so: lst = range(42) rows = [] while lst: row, lst = lst[:5], lst[5:] rows.append(row + [None]*(5 - len(row))) -ak -- Django by Example Tutorials: http://lightbird.net/dbe/ Pysuite - Python Vim plugins: http://lightbird.net/pysuite/ -- 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.
New tutorial added to Django by Example
I've added a new tutorial: Calendar App to my Django by Example site. As always, feedback is appreciated. What would be a good tutorial to do next? http://LightBird.net/dbe/ -ak -- 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: New tutorial added to Django by Example
On Aug 3, 3:27 am, Mario wrote: > Thank you for sharing the application. I would like to make the start > day of the week Sunday instead of Monday. > > _Mario All you have to do use calendar module's method to set starting day of week: calendar.setfirstweekday(calendar.SUNDAY) (and update template). -ak -- 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: New tutorial added to Django by Example
On Aug 3, 2:25 am, Nikhil Somaru wrote: > How to set up a virtual python/django installation > There is already a tutorial for this here: http://codytaylor.org/2010/07/django-on-dreamhost-virtual-python-install.html -- 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: Using foreignkey data as a primary key
On Nov 18, 9:04 am, JE wrote: > Hi, > > I'm pretty new to Django so feel free to laugh if something's > horrendously wrong here that I haven't spotted. > > I'm trying to use a field from a foreign key as a primary key in > another model, but have no idea how to do this. > The idea is to have a table called Tag (columns called tagname and > tagversion, which create a composite primary key using the > unique_together option in the metadata). > Why not just have a boolean column 'current' or 'active' in Tag model, instead of a separate table? On save, if it's changed inactive->active, all other tags are set to be inactive. -ak -- 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: Generic Views - do you use them?
On Nov 8, 6:42 pm, Ted wrote: > What are their pros and cons? How often do you use them when you're > coding? > > The more I code in django the less I find generic views to be useful > shortcuts (direct to template being the exception). > > My biggest complaints are: > * You don't end up saving many keystrokes unless you have 3 or more > views that are going to use the same info_dict. > * They can't be tweaked or changed much before you have to move the > code to the views file, destroying the keystroke savings. > * Second syntax for doing the same thing makes Django harder to > learn. > > Am I alone on this? > > I've thought about it and i think there is a better way. I want to > see if there are others in the community who aren't in love with > generic views before I develop the alternate approach. > > I'm not trying to start a flame war. They may be useful sometimes but I've never needed them as I usually work on open-ended projects that would grow out of generic views soon even if they may be possible to use at first. I think there's a problem with the way generic views are introduced in documentation. I've actually tutored someone on use of Django and we ran into a problem that they started using generic views and kept asking me how to do this or that with them and they could do almost nothing they wanted. I could see it was frustrating for the student. I think the docs should either completely move generic views into some optional section or there should be an extremely clear and explicit walkthrough of their limits and a disclaimer that you shouldn't use them unless you're pretty sure they can do everything you need your app to do. I think I've seen a web talk by Adrian where he said generic views were introduced for designers (i.e. non-programmers) to make it possible to make a useful app with no programming at all. I don't have a problem with that at all. The main issue is how the docs approach generic views.. -- 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: Django Team Project Best Practices
On Dec 9, 8:26 pm, "acat...@gmail.com" wrote: > I have been using Django for a little over two years as a freelance > developer. I am currently working at a company where I am at the > beginning stages of a two-person Django app. I have worked on group > projects before, quite some time ago, as an html editor. I definitely > don't have experience at developing a two-person Django project. I > have he envisioned initiating a django project, initiating an empty > app under that project, establishing template and static folders in > the project. After then I figured I would add the project to a github > repository then have my co-worker clone the project. After that we > could work away on separate branches and merge when ready. My co- > worker wants to have the repository only have the app part of the > project and the app will contain media and static folders. Each > developer would have a project root with only manage.py, urls.py and > the clone app. His thinking that this fits the Django way of doing > things more closely, but I don't see it this way and the only > explanation I can give is that I would be having all of the project's > files and folders in the standard django project folder. I would > greatly appreciate hearing from anyone with insight or advice. Thanks > in advance. His reasoning sounds very odd to me. What about sharing stuff between different apps? There's nothing in django that says a single app should be in a repo. The point of an app is that it's portable and can be moved around and other apps can use parts of it as needed. Repo setup depends on what changes you will need to share, if you're absolutely sure you'll only need to work on one app and it won't use anything from other apps, and you won't need to add custom app settings to settings.py, I guess it's ok but I don't see the point. For what its worth, I've been working with repos that contained django projects in two places and it works just fine. (and in fact it wouldn't work otherwise for the reasons I mentioned.) -- 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: Returning value directly to another function
On Dec 9, 9:21 am, Quetzacotl wrote:
> Hello, this is rather python problem, but maybe You can help. What i
> want to do is to return value in another function calling from other
> function.
>
> It doesnt mean i want this:
>
> def Func():
> return 1
>
> def Func2():
> return Func()
>
> I want function Func to return 1 directly in Func2 as it is Func2
> returning it.
>
> I have this problem because view function has to return response
> object and my function that adds element to database (comments)
> returns HttpResponseRedirect or context dict with form that has
> errors.
> If it returns redirect then i want view function to return it, if it
> return context then i dont want to return it but rather give it to
> render_to_response.
>
> It comes to this:
>
> def Add():
> #form valid, add to db
> return { 'redirect': HttpResponseRedirect('url'), }
>
> #form not valid
> return { 'form': form, 'redirect': 0, }
>
> def View(request):
> add = Add()
> if add['redirect']!=0:
> return add['redirect']
>
> return render_to_response(template,add)
>
> Thing i dont want here is if statement checking if there is redirect,
> so i want within function Add return HttpResponseRedirect as it is
> View function.
>
> I dont know if this is possible.
You can use isinstance() function to check if returned value is
an instance of some class, and make for simpler code:
obj = add()
if isinstance(Cls, obj): return obj
..
return render_to_response(template, obj)
--
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: Generic Views - do you use them?
On Dec 10, 4:04 am, Łukasz Rekucki wrote: > You should try the new class-based generic > views:http://docs.djangoproject.com/en/dev/topics/class-based-views/ > > They're much more flexible. Is there a doc somewhere that details what the limitations are? How do you tell if some task is definitely too much for new generic views? I'm not using 1.3 yet and generally what I've been doing recently doesn't seem to fit generic views but eventually I might use them. -- 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.
Django breaks shelve?
Hi, I have some shelved instances that were saved when a module was run from command line, but when it is run from inside django: from reminders import * Tasks() I get the standard shelve error: 'module' object has no attribute 'Task'. reminders module has classes Task and Tasks defined. If I create a test module test.py and do: from reminders import * Tasks() It works without error, so the issue is with some magic namespace manipulation Django is doing? -- 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.
get().delete() does not work, filter().delete() works?
Hi, I have a function that accepts a pk and deletes an object: Item.objects.filter(pk=pk).delete() If I change it to: Item.objects.get(pk=pk).delete() it no longer works, without any errors. I tried it using exactly the same object. I looked at django docs for deletion, the only difference they mention is that with .filter(), it will also do bulk deletion. What is the reason for this behaviour? 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. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: get().delete() does not work, filter().delete() works?
On Friday, March 16, 2012 2:50:25 PM UTC-4, Tom Evans wrote: > > 1) You have overridden the delete() method, and you don't call the > > super class method > Indeed, I had overridden it to create a delete column and forgot about it! Thanks. Rainy > -- 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/-/8NryXOYixNwJ. 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.
Combinable generic CBVs
When I use CBVs, I nearly always end up needing to mix different types in the same view, e.g. detail view and list view, list view and modelform view, etc. I really like CBVs but I feel this is the one shortcoming that I constantly run into that makes CBVs much less flexible and helpful than they could be. Current CBVs don't have built-in support for this because instance variables and methods have the same name, e.g. self.model, self.object in both detail view and model form view, get_context_data in all CBVs, and so on. I think it would be very useful to modify CBVs to make them combinable by using different variable and method names and having separate unified methods that combine data from specific methods: you'd have self.detail_object, self.modelform_object, get_detail_context_data, and get_context_data would check if get_detail_context_data (and other methods) exist and get data from all of them and return combined into one dictionary. It seems like it may be quite a bit of work, and I don't have much experience designing many levels of classes with Mixins, I'd like some advice on whether this is a good idea and how to implement it. Any suggestions / hints appreciated! -- 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/-/t4bjuYpfuhIJ. 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: Combinable generic CBVs
On Aug 29, 3:10 am, Melvyn Sopacua wrote:
> On 29-8-2012 4:44, Rainy wrote:
>
> > When I use CBVs, I nearly always end up needing to mix different types in
> > the same view, e.g. detail view and list view, list view and modelform
> > view, etc. I really like CBVs but I feel this is the one shortcoming that I
> > constantly run into that makes CBVs much less flexible and helpful than
> > they could be.
>
> What are your real world cases for this? If you combine several models
> to make up a page, you should consider writing your own mixins that
> inherit only from ContextMixin and implement get_context_data() to add
> the extra information.
> For example:
> class OnSaleMixin(ContextMixin) :
> on_sale_queryset = Products.objects.filter(on_sale=True)
> def get_context_data(self, **kwargs) :
> context = { 'on_sale_list': self.on_sale_queryset }
> context.update(kwargs)
> return super(OnSaleMixin, self).get_context_data(
> **context)
>
> class ProductList(ListView, OnSaleMixin) :
> model = Products
>
> --
> Melvyn Sopacua
I will give some examples at the end of the message, but first I want
to expand a bit on this idea.
Let's say you have a detail CBV, FooView(DetailView): model = Foo ;
and a list view, BarView(ListView): model = Bar .
Now, combining different types of views is an extremely common case
and you might say that the cases when you don't need to do that are
usually so simple that existing GCBVs already handle them perfectly.
Nobody ever complained that inheriting from a ListView and maybe
overriding one or two methods is hard to do. So the user case that
we need to optimize for is the one where difficulties lie and where
people have run into problems and complained about, blaming GCBVs
for being hard to use and debug.
I don't see any apparent reason why the two examples above can't
be combined exactly in the same way you inherit each separate view:
FooBarView(DetailView, ListView): detail_model=Foo; list_model=Bar.
As a bonus, you don't have to decide which mixin to use and when
overriding methods, you will know which instance variable and method
handles detail and list objects.
Here are a few examples where it would be useful, and I can find many
more in my projects:
- blog post: 3 CBVs: post, list of comments, comment form
- search: FormView, ListView
- photo album: detail view for album, listview of images
I know each of these cases can be handled with current GCBVs but
with a lot more effort and in a more verbose and error-prone way
than what I'm proposing.
--
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: Combinable generic CBVs
On Aug 29, 5:24 pm, Melvyn Sopacua wrote: > On 29-8-2012 18:46, Rainy wrote: > > > On Aug 29, 3:10 am, Melvyn Sopacua wrote: > >> On 29-8-2012 4:44, Rainy wrote: > > >>> When I use CBVs, I nearly always end up needing to mix different types in > >>> the same view, e.g. detail view and list view, list view and modelform > >>> view, etc. I really like CBVs but I feel this is the one shortcoming that > >>> I > >>> constantly run into that makes CBVs much less flexible and helpful than > >>> they could be. > > >> What are your real world cases for this? If you combine several models > >> to make up a page, you should consider writing your own mixins that > >> inherit only from ContextMixin and implement get_context_data() to add > >> the extra information. > > > > > I will give some examples at the end of the message, but first I want > > to expand a bit on this idea. > > > Let's say you have a detail CBV, FooView(DetailView): model = Foo ; > > and a list view, BarView(ListView): model = Bar . > > > Now, combining different types of views is an extremely common case > > and you might say that the cases when you don't need to do that are > > usually so simple that existing GCBVs already handle them perfectly. > > The list and detail view don't bite each other in many aspects. However, > as you will list in examples below, you usually don't have just one list > view per page. See below. Actually, I've never had more than one list per view, either in these examples or in any other I've worked with. In fact, I've never had a view where more than one instance of any type of CBV was needed, as far as I can remember. The only common case I can think of is having two forms - let's say a search and login. I think it should be handled as a special case, maybe allowing form_model to be a list and updating all CBVs to process it as either a single item or as a list. > > > I don't see any apparent reason why the two examples above can't > > be combined exactly in the same way you inherit each separate view: > > FooBarView(DetailView, ListView): detail_model=Foo; list_model=Bar. > > Because how would you declare a second list model? And how would you > pick these up? Aside from making the routing through the model > difficult, this will also be a declaration nightmare. I showed examples below, doesn't seem like a nightmare, I think.. > > > As a bonus, you don't have to decide which mixin to use and when > > overriding methods, you will know which instance variable and method > > handles detail and list objects. > > Except when you need more than one list or detail or both. > > > Here are a few examples where it would be useful, and I can find many > > more in my projects: > > > - blog post: 3 CBVs: post, list of comments, comment form > > - search: FormView, ListView > > - photo album: detail view for album, listview of images > > > I know each of these cases can be handled with current GCBVs but > > with a lot more effort and in a more verbose and error-prone way > > than what I'm proposing. > > I don't see that: > class BlogView(CommentListMixin, CommentFormMixin, DetailView) : > model = BlogPosts > > versus: > class BlogView(DetailView, ListView, CreateView) : > detail_model = BlogPost > list_model = Comments > form_model = Comments > > I find the second version harder to read, more verbose to type and when > you want to support multiple models you will have to support some sort > of sequence or mapping. It's ok that it's more verbose, in fact it's a good thing becase here verbosity is moved from method level to class attribute level, I want my methods to be as short and clear as possible, to make it easier to follow the logic. > Not to mention how you'd handle template-coder > friendly names through context_object_name and similar. Of course, this would be done with declarations like context_detail_object_name, etc, only for objects that need to be accessed in template. In this case, context_create_object_name is probably not needed and can be left as None. > > Yes, the first version requires more work to code the mixins, but I > don't find them harder to debug either. In fact, pretty much only one > point where things can go wrong: get_context_data(). No, the issue is the clash between self.object, context_object_name, self.model. You have to look through the entire tree of CBVs and make sure all of them refer to the correct objects everywhere they're referenced. For example, self.object is
Re: Passing variables from a context processor to a template
On Jan 5, 12:35 pm, Guy Nesher wrote:
> Thanks,
>
> I've initially tried to use a dictionary but was still unable to pull
> the data in the template.
>
> I'm using your updated context processor:
> def swiss_context_processors(request):
> added_context = { 'mytest': 'aaa', }
> return added_context
>
> and trying to call {{added_context.mytest}} in the template which
> returns nothing
It should be just {{ mytest }}
Also note that a comma at the end is not necessary:
return {'mytest': 'aaa'} or even return dict(mytest='aaa')
-ak
--
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: Passing variables from a context processor to a template
On Jan 5, 12:38 pm, Rainy wrote:
> On Jan 5, 12:35 pm, Guy Nesher wrote:
>
> > Thanks,
>
> > I've initially tried to use a dictionary but was still unable to pull
> > the data in the template.
>
> > I'm using your updated context processor:
> > def swiss_context_processors(request):
> > added_context = { 'mytest': 'aaa', }
> > return added_context
>
> > and trying to call {{added_context.mytest}} in the template which
> > returns nothing
>
> It should be just {{ mytest }}
I should add that in Python, it doesn't matter what is the
variable name of value being returned. So if you have
def x(): a=1; return a
def y(): b=x()
There is no way for y() to know that inside x(), the
variable was called 'a'. It receives the value only. It's
effectively equivalent to x() being:
def x(): return 1
So you need to understand that django template
processing receives the dictionary {'mytest':'aaa'} and
could not possibly know what you mean by 'added_context'.
-ak
--
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.
modular CBVs
Hi, I've written modular class-based views, based on generic views distributed with Django, and uploaded the initial version today: http://lightbird.net/mcbv/ The main difference vs. generic CBVs is that you can easily combine different views together, e.g. detail, create, list - in a single view without any extra work. I've also added FormSetView which works similarly to UpdateView and FormView. I'd be glad to hear some feedback on my implementation.. 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. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Why doesn't form_valid() in FormView take a request argument?
On Wednesday, February 6, 2013 3:09:39 PM UTC-5, Some Developer wrote: > > Why doesn't the form_valid() (and for that matter the form_invalid()) > method in the FormView generic class based view take a request argument? > > I've found that if you have a form which requires you to override the > form_valid() method because you need to do custom logic before you save > the model and you need to save the user ID of the person who posted the > form you need to also override the post() method in order to pass on the > correct data by manually adding it to the post argument of the > form_valid() method by using request.user. > > Am I missing something here? Is there any easier way to achieve what I > want to achieve? > How about using self.request attribute? -rainy -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Why doesn't form_valid() in FormView take a request argument?
On Thursday, February 7, 2013 3:39:43 AM UTC-5, Some Developer wrote: > > On 06/02/13 23:00, Rainy wrote: > > On Wednesday, February 6, 2013 3:09:39 PM UTC-5, Some Developer wrote: > > > > Why doesn't the form_valid() (and for that matter the > form_invalid()) > > method in the FormView generic class based view take a request > > argument? > > > > I've found that if you have a form which requires you to override > the > > form_valid() method because you need to do custom logic before you > save > > the model and you need to save the user ID of the person who posted > the > > form you need to also override the post() method in order to pass on > > the > > correct data by manually adding it to the post argument of the > > form_valid() method by using request.user. > > > > Am I missing something here? Is there any easier way to achieve what > I > > want to achieve? > > > > > > > > How about using self.request attribute? -rainy > > Heh I don't know how I missed that. Thanks, that solves a couple of > issues :). > > I'm in the process of converting some old code to class based views and > am still getting used to using them. > > No problem. There's of course also self.args and self.kwargs. If you need to use views that inherit from multiple CBVs, take a look at my tutorial that uses modified GCBVs: http://lightbird.net/dbe2/ (I will add more tutorials in near future) HTH, -rainy -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Updated Django by Example tutorials
Hi, I've started updating Django by Example tutorials for django version 1.5 and using class-based views. I have posted 3 tutorials so far; 3 more will be added soon: http://lightbird.net/dbe2/ I hope these will prove to be useful.. please let me know of any issues / ways to improve the guide. - rainy -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Updated Django by Example tutorials
On Monday, February 11, 2013 11:24:57 PM UTC-5, Rainy wrote: > > Hi, I've started updating Django by Example tutorials for django version > 1.5 and using class-based views. > I have posted 3 tutorials so far; 3 more will be added soon: > > http://lightbird.net/dbe2/ > > I hope these will prove to be useful.. please let me know of any issues / > ways to improve the guide. > > - rainy > I have added a new tutorial -- Issues Tracker: http://lightbird.net/dbe2/issues.html It contains a nice example of making custom multi-fields. - rainy -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: I need a form that allows users to select from a list of choices, or add a new choice.
On Wednesday, February 27, 2013 11:28:50 AM UTC-5, Mark London wrote: > > I need a widget or a method that allows users to select items from a list > of choices, or add a new choice. Someone on stackoverflow asked the same > question, and got a kludgy answer: > > > http://stackoverflow.com/questions/14802167/how-do-i-make-a-django-choicefield-accept-both-preset-choices-and-the-addition- > > There should be a better way than this. Thanks. > > - Mark > Take a look at SelectOrCreateField (and its widget) here: http://lightbird.net/dbe2/issues.html#selectorcreatefield The screenshot is here: http://lightbird.net/dbe2/issues.html#addissues-template -ak -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Inspecting form errors in a view
On Thursday, March 21, 2013 5:07:36 PM UTC-4, aub...@deepearth.co.uk wrote: > > Hello, > > I have form class that has a relatively lengthy clean method which does > field > validation (as the validity of fields depends on the values of fields) as > well > setting error messages on the form itself. I also intend to be part of an > app > used in multiple views in a few projects. > > I want to run certain actions (aside from the usual slew of validation > failure > messages) based upon 1) the view in the which the form is being used 2) > which > clean checks fail. These actions may also need to alter the http response, > possibly adding items to the context of the template to be rendered and > possibly changing which template to use all together. > > I'm relatively new to the Django framework and I was wandering if anyone > had > ideas what might a good way to go about this. > > Below are current thoughts on the problem: > > + Have the validation function set variables on the form when validation > checks fail and use these in the view to determine what action to run. > The > problem with this is would mean subclassing existing Django classes and > altering them to set attributes when the built in validation checks > fail. > I believe you can just set self.my_flag = foo in clean method and then check for that. -ak -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Inspecting form errors in a view
On Thursday, March 21, 2013 9:47:03 PM UTC-4, Aubrey Stark-Toller wrote: > > On Thu, Mar 21, 2013 at 03:40:39PM -0700, Rainy wrote: > > I believe you can just set self.my_flag = foo in clean method and then > > check for > > > Cheers for the reply. > > I suspect my original mail could have clearer. Just setting attributes > when > checks fail seems to me to be the best way to do this, but it does mean > that > if I need to check if, say, an integer field is invalid as it contains a > string then I'd to reimplement this validation in the clean method so that > it > sets the necessary attribute on the form, and so on for any other field > clean > methods that I may need to use and check. > > I realise this is a little beyond what Django's forms where meant for and > I > might have to live without some of Django's built-in validation to get > this > to work, but I'd thought I'd see if anyone here had any thoughts. > > Aubrey > Hi Aubrey, I'm not sure why you think you'll need to override individual clean methods for fields. You write: I have form class that has a relatively lengthy clean method which does field validation (as the validity of fields depends on the values of fields) as well setting error messages on the form itself. So my suggestion is to check, in that single clean method, which fields have errors and to set your flags accordingly. HTH! -ak -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Understanding UpdateView with forms and formsets
On Monday, April 8, 2013 12:22:34 PM UTC-4, Nora Olsen wrote:
>
> Hi,
>
> I'm a new user to Django.
>
> I'm trying to understand how does an UpdateView works when during a POST.
> Is there some state carried between the GET and POST, because I don't see
> the pk in the form. How does the form save() knows that it should be
> updating instead of inserting?
>
> The reason I'm asking is because I am having trouble trying to save a
> formset that is used in a view together with the main form. I posted the
> question on stackoverflow:
> http://stackoverflow.com/questions/15877199/using-formset-with-contenttype
>
> I am trying to save Item with multiple Pictures in a single form.
>
> I can easily save the item form in the Post method of the view but I can't
> save the formsets without the pk. In my template, I have the following:
>
>
> {% for field in form %}
> # do something
> {% endfor %}
>
> {{ picture_formset.management_form }}
> {% for form in picture_formset.forms %}
> # do something
> {% endfor %}
>
>
>
>
> And my view:
>
>
> class ItemUpdateView(UpdateView):
>
> form_class = ItemCreateForm
> template_name = 'item/new.html'
> model = Item
> success_url = '/items/'
> def get_context_data(self, **kwargs):
> context = super(ItemUpdateView, self).get_context_data(**kwargs)
> item = context['object']
> # Dont' create any extra forms when showing an update view
> PictureFormSet = formset_factory(PictureForm, extra=0)
> return {'form': kwargs['form'],
> 'picture_formset': UploadFormSet(initial = [
> model_to_dict(a) for pic in item.pictures.all()])}
> def post(self, request, *args, **kwargs):
>self.object = self.get_object()
>item_form = ItemCreateForm(request.POST, instance=self.object)
>if item_form.is_valid():
>item = item_form.save(commit=False)
>item.save()
># How do I update the pictures?
>
>
> I did manage to solve this by adding the pk as a HiddenWidget and
> obtaining the Picture model before updating the keys/values and saving it.
>
> But I had to create 2 type of forms: with and without the pk for the
> CreateView and UpdateView.
>
> Is this the correct approach?
>
Hi Nora, the way it works is that it uses get_object() method to load the
object; at the top of post() method,
it has the line: self.object = self.get_object().
If you need to use modelformset together with a form or modelform in one
view, you might
want to look at my mcbv library; it has both a modelformset CBV and also
allows to easily
combine different types of views together.
The portfolio tutorial has a good examples of doing just that:
http://lightbird.net/dbe2/portfolio.html
mcbv library itself currently lives here: https://github.com/akulakov/django
-ak
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Understanding UpdateView with forms and formsets
Sorry, I answered before reading your full message. It looks like you understand post loads the object in get_object(). I just want to add that combined create/update can be done in different ways; I have an implementation in mcbv.edit module but I'm not sure if it's the best approach in all cases. I don't think having two forms is a problem, you can have one form for update and then inherit and modify as needed for create. -ak -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Django-Registration/Custom Authentication Issue
On Sunday, April 14, 2013 9:49:32 PM UTC-4, Lee Hinde wrote: > > I'm trying to do a 'simple' registration with just a user email and > password required to create an account. I'm using django-registration with > django 1.5.1 and have created a custom model and the custom model manager. > > I can hit all the registration forms just fine and have copied the example > from the django docs (ignoring, temporarily, the admonition not to do > that.). > > I've created a custom backend in django-registration, basically to remove > the username requirement. In fact, my custom backend is identical to the > default, minus any references to the username. > > When I try to create a new user (i.e, submit the form), from > /accounts/register/ I get the following error: > > AttributeError at /accounts/register/ > Manager isn't available; User has been swapped for 'letters.PCSUser' > > The full trace back is: > > File "/Library/Python/2.7/site-packages/django/core/handlers/base.py" in > get_response > 115. response = callback(request, > *callback_args, **callback_kwargs) > File "/Library/Python/2.7/site-packages/django/views/generic/base.py" in > view > 68. return self.dispatch(request, *args, **kwargs) > File > "/Users/leehinde/Documents/Clients/ProfessionalCreditSolutions/pcs/pcs/registration/views.py" > > in dispatch > 79. return super(RegistrationView, self).dispatch(request, > *args, **kwargs) > File "/Library/Python/2.7/site-packages/django/views/generic/base.py" in > dispatch > 86. return handler(request, *args, **kwargs) > File > "/Users/leehinde/Documents/Clients/ProfessionalCreditSolutions/pcs/pcs/registration/views.py" > > in post > 35. return self.form_valid(request, form) > File > "/Users/leehinde/Documents/Clients/ProfessionalCreditSolutions/pcs/pcs/registration/views.py" > > in form_valid > 82. new_user = self.register(request, **form.cleaned_data) > File > "/Users/leehinde/Documents/Clients/ProfessionalCreditSolutions/pcs/pcs/registration/backends/pcs/views.py" > > in register > 80. > password, site) > File "/Library/Python/2.7/site-packages/django/db/transaction.py" in inner > 223. return func(*args, **kwargs) > File > "/Users/leehinde/Documents/Clients/ProfessionalCreditSolutions/pcs/pcs/registration/models.py" > > in create_inactive_user > 78. new_user = User.objects.create_user( email, password) > File "/Library/Python/2.7/site-packages/django/db/models/manager.py" in > __get__ > 256. self.model._meta.object_name, self.model._meta.swapped > > > No doubt I've left out some needed component to show why this error is > coming up, but I'm not sure what. I'm grateful for any pointers on where I > should be looking. > > > I believe the issue is that you need to define usermanager on your custom user, and you will possibly need to inherit from django usermanager and override it to not use username anywhere. But at the very least, you need to do something like: import UserManager from wherever class CustomUser(User): objects = UserManager() -ak -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: django-social-auth problem with facebook
When you get this error, you need to look at your database error log, e.g. for postgres 8.4 on linux: tail -n100 /var/log/postgresql-8.4-main.log It should tell you the exact sql command that caused the first error (you might need to scroll up). On Monday, April 15, 2013 2:01:21 AM UTC-4, Jeff Hsu wrote: > > Hi, I just pip installed django-social-auth from omab today on > github(beginner here). I think I can almost get it to work with facebook > login, but I always have this "InternalError: Exception Value: current > transaction is aborted, commands ignored until end of transaction block", > after I log in with my facebook account and before I redirect to the > profile page. The request url shows > > http://127.0.0.1:8000/complete/facebook/?redirect_state=xxx&code=xxx&state=xxx. > > I'm using Django 1.5. Can anybody give me some directions to debug this? > > Thank you tons, > Jeff > > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Possible Basic kwargs question.
When the definition is method(self, **kwargs), you ARE asking variable named kwargs. If you want to accept one dict object, it should be: method(self, mydict). If you want to accept variable list of args, it should be method(self, *mylist) -ak On Wednesday, April 17, 2013 12:59:21 AM UTC-4, jayhalleaux wrote: > > but if I did that then i would have a variable named kwargs. > > and it would be print kwargs['param1'], etc > > Why even unpack the dictionary? I could just pass the dictionary instead. > > > On Tuesday, April 16, 2013 11:08:42 PM UTC-4, Brad Pitcher wrote: >> >> It should be: >> model.method1(**params) >> On Apr 16, 2013 7:49 PM, "jayhalleaux" wrote: >> >>> Not really a Django question but I'm trying to create a model method >>> that does not have a fixed set of parameters. >>> >>> models.py >>> Class Model_A(model.Model): >>> ... >>> >>> def method1(self, **kwargs): >>> >>> print param1, param2, param3 >>> >>> >>> >>> views.py >>> params = dict( >>> >>> param1=something1, >>> param2=something2, >>> param3=something3, >>> ... >>> >>> ) >>> >>> model.method1(params) >>> >>> In this example when I try to do something like this it states that I >>> should have passed only 1 parameter instead of 2. >>> >>> I thought the whole point of using '**' to unpack dictionaries is so you >>> don't have to have a fixed number of parameters. >>> >>> Is there something I am missing or am I doing this incorrect? First time >>> I'm trying to create a method like this. Normally I explicitly state all >>> parameters. >>> >>> Any help is appreciated. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-users...@googlegroups.com. >>> To post to this group, send email to django...@googlegroups.com. >>> Visit this group at http://groups.google.com/group/django-users?hl=en. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: django 1.5 not getting css
On Sunday, April 21, 2013 11:18:22 AM UTC-4, Carlos Aboim wrote: > > Hi everyone. > > Anybody can tell me why I can get css on my flatpage /home/ ? > > http://dpaste.com/hold/1066757/ -> this is the html of the page > > http://dpaste.com/hold/1067747/ ---> this is the css styles > > http://dpaste.com/hold/1066760/ -->settings.py > > http://s22.postimg.org/78tbfibzl/Picture_2.png --> folder estruture > > thank you > Comments above STATIC_ROOT explain what it should be set to. -ak -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
admin: allow changlist view but not changeform
Hi! I'm working on a site where I'd like to allow changelist view with sorting, filters, search and links to other custom views, but I want to block users from using changeform. I'm thinking of overriding the change_form template and adding a check there for user.is_superuser (for whom I do want to allow change_form), and displaying an error for all other users. Only one model needs to be managed in this way. There are no inline formsets for editing this model. Is this a robust and secure approach? Thanks! -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Generic Views - do you use them?
On Dec 10, 5:22 pm, Łukasz Rekucki wrote: > > On Fri, Dec 10, 2010 at 9:37 AM, Rainy wrote: > > >> Is there a doc somewhere that details what the limitations are? How > >> do you tell if some task is definitely too much for new generic views? > >> I'm not using 1.3 yet and generally what I've been doing recently > >> doesn't seem to fit generic views but eventually I might use them. > > What kind of limitations you have in mind ? Well, not exactly sure. I looked at them a bit more and actually they look kind of nice. I think calling them generic views may be a bit misleading at this point because a lot of people probably will end up using them for all complex views while leaving functions for simpler ones. In other words, you might use predefined generics for the most basic views, then use functions for slightly more complicated ones and custom generic for everything else. -rainy -- 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: How to get a web development job (i.e. Django/Python) if someone is an amateur programmer?
In addition to what other mentioned, I recommend looking daily at sites like elance and rentacoder and making small apps / scripts for practice, even if you can't make a bid. This will be very useful because: 1. you'll have a good idea on what people are paying for, 2. you'll accumulate your own code that can be reused, 3. eventually if you see something close to what you've done you can make a competitive bid even if you have little experience. There are a lot of low-balling and otherwise bad clients there but it still gives you good experience that will be useful later on. Good luck, -rainy -- 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: Django's documention is horrible
On Jan 11, 3:36 am, mrmclovin wrote: > On Jan 11, 7:44 am, Sam Lai wrote: > > > > > > > > > > > On 11 January 2011 13:39, Christophe Pettus wrote: > > This isn't about patches to the existing docs (which are great for > > their purpose). It is about Django missing an API reference manual, > > something like .NET Class Library Reference > > (http://msdn.microsoft.com/en-us/library/gg145045.aspx), PHP's > > Function Reference (http://www.php.net/manual/en/funcref.php) or > > Java's (rather hideous looking) API reference > > (http://download.oracle.com/javase/6/docs/api/). > > > I'm glad someone brought this up (although 'horrible' seems like too > > strong a word). I miss not having these docs in some online form > > because once you know enough about Django, you often know that Django > > has capability x but you don't remember what class/namespace it is in. > > You end up having to google and spend a while locating the info in the > > existing docs. Browsing or grepping the code isn't much better (maybe > > I'm missing an app or two here). > > > API docs also tend to be more structured and concise so you can > > instantly see what parameters take what, what exceptions might be > > thrown, what the return value is/represents etc. > > > Right now, I almost always have a browser tab open to > > code.djangoproject.com for this purpose. > > > Talk/ideas are cheap, so here's my take on possible API docs for Django - > > > An API reference site structured in a similar manner to the above > > examples, with the ability to easily search; integrated pydocs; links > > to relevant sections of the Django docs; a link to see the code of the > > function/class/method etc. A wiki-style section for each page would be > > nice too to document caveats, tips, tricks, relevant snippets etc. > > > Of course the dynamic nature of the code makes this harder to do and > > will probably require some human intervention to ensure an entry > > exists for every parameter, mapped method etc. > > > P.S. what's the short answer to why the current Django docs aren't on > > a wiki site instead of being versioned inside SVN? > > > There are some minor clarifications here and there that I'd like to > > add, but the overhead of producing a patch, creating a ticket, > > flagging down a committer, getting a consensus, and finally having the > > patch committed is a bit off-putting. I can understand the process for > > code, but it just seems a bit over-the-top for docs. Maybe a > > compromise would be adding something like the per-paragraph comments > > that The Django Book site has; that way the docs stay official, yet > > there's still a way for users to add to them. > > > > -- > > > -- Christophe Pettus > > > x...@thebuild.com > > > > -- > > I guess your post should be replaced by my first one :). It's exactly > what I was trying to say: django need a reference manual to complement > the existing documentation. > > On Jan 11, 8:55 am, James Bennett wrote: > > > If your computer is incapable of running pydoc, epydoc or other > > similar scripts, how is it simultaneously able to run Django? > > -- > > "Bureaucrat Conrad, you are technically correct -- the best kind of > > correct." > > If you bought a game, would you rather like to get info on how to > compile the game in order to play it.. or just install it and play it? That's a stupid analogy, django devs have limited time and there are things in django itself and existing docs that could be improved. I would prefer if they spent the time on more important things rather than relatively less important, e.g. things that can be done automatically by modules like pydoc. OTOH I would also appreciate it if someone made an nice online module reference for django. I don't need it very often, but when I do, it'd be nice to have, no doubt. I think it's unfair to say Django docs are bad -- to the contrary, they're the best docs I've seen in an open source project. And forum interfaces and especially searching is pathetically bad, I always end up using google to search forum sites instead of built-in search. -- 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: Django's documention is horrible
On Jan 12, 7:18 am, Mike Dewhirst wrote: > OK - so we need an intro to the documention which describes the timeline > of a typical* developer transitioning from beginner to guru and the docs > which should be of interest at successive stages during that transition. > > *typical - I know there ain't such a person. However, there ought to be > a "target audience" the Django Foundation wants to reach. That person > becomes the target audience for the intro and gets described in the > intro to the intro. > > If the intro works other "typical" devs can be described for alternative > intros. Too meta huh? > > Problem is there are too many small operators who need more than Django. > Such as aesthetic guidance, CSS etc etc > > It's a quite daunting curve but really all anyone needs is to know where > to find the docs appropriate to their current stage. > > How about a survey where people tick boxes which describe where they > currently sit on the continuum so that existing gurus can see how the > first "typical" dev can be described. I wonder if anyone keeps track of categories of questions asked on this list and on stackoverflow. Something like: In last 2 years: total: x questions admin: 250/x views: ... templates: ... (but with more detailed subcategories). If anyone has done this, please share because this would be very useful to all django doc/tutorial authors. -ak -- 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: Can someone help with Many-to-many referencing and then calculations against another field on the linked model
On Jan 20, 2:04 pm, Trevor Stanley wrote:
> Kenneth
>
> That is what I originally though but if I write that this is the error I
> get:
>
> in _get_fringe_value
> ft = Fringe.objects.select_related().filter(id=self.id).values()
> AttributeError: 'str' object has no attribute 'id'
>
> I'm in London and I do this in my spare time so have just arrived home
> from work. Many thanks for looking at this for me.
>
>
This line isn't right:
fringe_value = _get_fringe_value('aqft')
Not sure what you're trying to do, if first arg
to that function is self, you should use it
as an instance method, e.g.
detail = Detail(...)
detail._get_fringe_value()
If you want to pass it a second arg, change
def line to accept a 2nd arg and call with:
detail._get_fringe_value('aqft')
-ak
--
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: local variable 'qft' referenced before assignment
On Jan 24, 1:46 pm, Trevor Stanley wrote:
> Bruno
>
> I will take your advice and seek out some Python literature. I did run
> through an online Python tutorial about a year ago. I should probably
> go through it again as I may understand it more now.
>
> Thanks, even though your delivery is rather blunt - Trevor
>
It seems like the problem is that you're trying to do
fairly complex things in django when you don't
have good understanding of python. Simply
reading python tutorial will help but probably
won't be enough, I would recommend doing a
few small, simple projects in plain python to get
a good practical knowledge of how functions,
lists and dictionaries work.
In the above code, you apparently thought that
in line qft=ft(sum('percentage')) ,
percentage field will somehow be extracted from
ft and then summed. You should understand that
the line is equivalent to
mysum = sum('percentage')
qft = ft(mysum)
Then you'd certainly see that sum('percentage')
is trying to make a sum out of the string. Again,
this is a tidbit of basic python knowledge that
you have to have a perfect grip on before
doing the type of project that you have here.
It's ok to try things and run into errors. But you
have to have a better grasp on fundamentals
when you do that. In the above example, adding
a sum() call inside a call to ft and giving it a field
name as argument is as likely to work as doing
ft('percentage') # please sum
or
ft{'percentage':sum}
or a million of other things that won't work and
result in confusing errors.
Walk before you run and all that.. HTH, -ak
--
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: using return upper
On Feb 1, 6:12 pm, makayabou wrote:
> Hello,
> I try to simplify the problem.
>
> This model gives me a (None) result:
>
> class OperatingSystem (models.Model):
> operatingsystem = CharField (max_length=30, blank=True, null=True)
> def __unicode__(self):
> return "%s" % (self.operatingsystem)
> class Ordi(models.Model):
> architecture = CharField (max_length=30, blank=True, null=True)
> operatingsystemused = ManyToManyField(OperatingSystem, null=True,
> blank=True)
>
> def __unicode__(self):
> oses_installed =
> u','.join(self.operationsystemused_set.all().values('operatingsystem',flat=
> True))
> return ("%s" % (oses_installed)).upper()
>
> Or also the same with that last line:
>
> return models.join(list(self.operatingsystemused))
>
> What can I do??
>
> thanks
How about
self.operatingsystemused.all().values('operatingsystem',flat= True)
-ak
--
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 IDE + FTP
On Feb 8, 3:30 pm, Karen McNeil wrote: > I have three Django sites that I've been working on recently and I've > been doing most of the development work in Dreamweaver. I don't use > any of the wysiwyg features (or, pretty much, any of the Dreamweaver > program features), but I like it because I can do all the the code > edits and the FTP transfers all in one program. I like being able to > grab a remote file, make some code changes, save and upload all at > once, and view a nice graphical display of the file structure for the > local and remote sites. > > Problem is, Dreamweaver's code view is definitely not built for > Python, and it doesn't look like they have any plans to support it any > time in the foreseeable future. Which means that I get no color- > coding of the code, and I'm constantly getting indentation errors. > > I've always had Dreamweaver on my computer (a Mac) and so have never > used a separate FTP program, and the only IDE I've ever used is IDLE. > I used IDLE when I was first learning Python, but now that I'm working > with the websites, I find it much more convenient to just open the > files from within DW. Does anyone know of another, Python-friendly, > program that I could use for both code-editing and ftp? > > Thanks, > Karen I recommend Gvim, although it takes time to configure and tune it. As for uploading, simply run a devserver locally and then after a few days (or a week) of work, upload everything in bulk, perhaps using a version control system. Basic use of version control is actually very easy to pick up and the nice bonus is that you can clean up code as needed, deleting parts that you don't use anymore, without fear of losing them: you can always go back in history and retrieve it. This leads to cleaner code IME. -- 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: South - when to start?
On Feb 18, 10:59 am, ShawnMilo wrote: > Just to add my tiny bit to this: > > I say start with South right away. But when you're ready to deploy for the > first time, wipe it all and to another --initial. > > The reason is that South is awesome for letting you upgrade a production app > that isn't allowed to stop working. So at first deployment, it's nice to > start clean so you don't have all those extra migrations for each run of > your unittests, etc. > > Shawn I was going to say the exact same thing. I can just add that anything is fairly easy with South - starting from the beginning, starting just before 2nd dev joins in, or even starting after other devs join. Wiping out old migrations is also easy. -Rainyday -- 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: pgadmin vs schema migration
On Feb 24, 9:54 am, ggavy wrote: > Thanks. It's good to get a little second opinion. I'm sure I'll make > the switch to migration tools eventually as things become a little > more involved. > > Cheers > gav I think the only possible danger is that you might forget to toggle an option like IS NULL in pgadmin or use a slightly different field type and then when you deploy somewhere else and use syncdb, the db layout will be different, which may or may not be a problem. Having said that, I usually find pgadmin to be a bit easier to use and for small changes it's just fine. South will slow down unittests because all migrations have to be applied in sequence, and then you might want to reset history and that's a bit of hassle, too. -Rainyday -- 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.
natural keys for auth.user and group
Hi, I know natural keys possibly will be added to auth.user and group in 1.4. I'm using 1.2 currently and I'm trying to add them dynamically: class UserManager(models.Manager): def get_by_natural_key(self, username, first_name): return self.get(username=username, first_name=first_name) class GroupManager(models.Manager): def get_by_natural_key(self, name): return self.get(name=name) def unatural_key(self): return (self.username, self.first_name) def gnatural_key(instance): return (self.name,) User.objects = UserManager() Group.objects = GroupManager() User.natural_key = unatural_key Group.natural_key = gnatural_key It seems like it should work.. (?) but I get this error when trying to serialize using natural keys: Traceback (most recent call last): File "data.py", line 362, in Backup().main() File "data.py", line 333, in main if options.dump: self.do_dump(default_datafile, self.classes) File "data.py", line 232, in do_dump use_natural_keys=True) File "/usr/local/lib/python2.6/dist-packages/django/core/serializers/ __init__.py", line 87, in serialize s.serialize(queryset, **options) File "/usr/local/lib/python2.6/dist-packages/django/core/serializers/ base.py", line 39, in serialize for obj in queryset: File "/usr/local/lib/python2.6/dist-packages/django/db/models/ query.py", line 106, in _result_iter self._fill_cache() File "/usr/local/lib/python2.6/dist-packages/django/db/models/ query.py", line 760, in _fill_cache self._result_cache.append(self._iter.next()) File "/usr/local/lib/python2.6/dist-packages/django/db/models/ query.py", line 230, in iterator fields = self.model._meta.fields AttributeError: 'NoneType' object has no attribute '_meta' Is there a way to do this without patching django? thanks, -ak -- 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: natural keys for auth.user and group
I fixed the earlier issue, which was happening during serialization, by using add_to_class() class method, but now I'm running into an issue with deserialize(): [...] for deobj in deserialize(fmt, val, ensure_ascii=False, use_natural_keys=True): File "/usr/local/lib/python2.6/dist-packages/django/core/serializers/ json.py", line 38, in Deserializer for obj in PythonDeserializer(simplejson.load(stream), **options): File "/usr/local/lib/python2.6/dist-packages/django/core/serializers/ python.py", line 127, in Deserializer data[field.attname] = field.rel.to._meta.get_field(field.rel.field_name).to_python(field_value) File "/usr/local/lib/python2.6/dist-packages/django/db/models/fields/ __init__.py", line 471, in to_python raise exceptions.ValidationError(self.error_messages['invalid']) django.core.exceptions.ValidationError: [u'This value must be an integer.'] This happens on a user value that's a natural key; in serializers/ python.py, the code looks for get_by_natural_key() method, does not find it and tries to process the id as int, which causes this exception. How can it be that dynamically updated manager works fine on serialization but not on deserialize? Thanks, any hints / ideas are appreciated. -ak -- 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.
