What's available in a view
This is somewhere between an observation and a question. I am writing a view that needs to know "some stuff", in particular HTTP_ACCEPT_LANGUAGE. As I read the developing book and look at the on- line documentation, it is not clear what is available and, probably more important, what is good practice to use it. To that end, I am going to toss out a more generic comment. Unfortunately, I don't have a good explanation to back it up. When I read "Agile Web Development with Rails" I felt that while I am more comfortable with Python and Rails seems a bit convoluted to me, that I knew more along the way. That is, with that book, I found the author anticipated my next question most of the time. I don't know how to define this but the approach in that book (and Programming Ruby) somehow makes things seem easier. I think that is going to be an important piece of promoting Django so consider this an observation from an outsider looking in rather than any serious criticism. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: What's available in a view
On Mar 8, 8:39 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 3/8/07, fyl <[EMAIL PROTECTED]> wrote: > > > This is somewhere between an observation and a question. I am writing > > a view that needs to know "some stuff", in particular > > HTTP_ACCEPT_LANGUAGE. As I read the developing book and look at the on- > > line documentation, it is not clear what is available and, probably > > more important, what is good practice to use it. > > I agree that it's something we need to work on, especially with views; > unfortunately, a view can technically do absolutely anything that's > legal to do in Python, so long as it accepts a 'request' argument and > returns an HttpResponse, so it's a bit of a hurdle :) > > With respect to the Accept-Language header, the request/response > docs[1] mention that it, and any other HTTP headers you want to look > at, are available in request.META -- in this case, it's > request.META['HTTP_ACCEPT_LANGUAGE']. > > [1]http://www.djangoproject.com/documentation/request_response/ First, thanks for the answer--I actually had figured it out later but is good to get it on the table here. I am not sure why I didn't quickly look in the documentation you suggest. I actually have it (and lots more) printed and sitting here as well as the obvious on-line link. But, maybe the fact that I didn't--but, rather, looked everywhere where views were generally addressed indicates the problem I am trying to explain. My goal here is to help lower the "entry fee" for Django, not to criticize. What you have said here is very clear and, in fact, saying something like this at the beginning of the information on views (and then going on to explain the difference between "technically can" and "makes sense to" I feel would be a huge help to a newbie. This comment really does go beyond views. For example, in models, there are cases where a "regular Python answer" makes sense (for example, wanted to set an expiration date field to the current date plus an increment) but, because you are thinking in a "Django context" you tend (ok, I tend) to look for a Django-related answer (such as auto_now+30). The generic answer may be as simple as a list of "what you can do" (for the model it exists as the definition of all the field types) and then a simple "if it isn't here, you can do it with Python" statement. Sorry if it sounds like I am picking on Django here but it will seem very intimidating to someone looking at it. I feel there needs to be some "clues" to keep people moving in the right direction. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Admin dies when foreign key added
I am getting an error in admin when trying to do an add. The error is mentioned in bugs but not related to the condition I have. It is 'bool' object has no attribute 'get' in get_manipulator_fields, line 112. Here are parts of my model: class Agent(models.Model): uid = models.IntegerField() pub_name = models.CharField(maxlength=60) ... class Listing(models.Model): title = models.CharField(maxlength=60) agent = models.ForeignKey(Agent) active = models.BooleanField(default=True) ... class Photo(models.Model): ##agent = models.ForeignKey(Agent) ## add agent blows up with the above line ??? agent = models.IntegerField() sequence = models.IntegerField(maxlength=1,core=True) listing_record = models.ForeignKey(Listing) ... It works fine as shown but, if I change the agent = line in Photo to be the commented out line, I get this error. The other ForeignKey fields seem just fine. Using SVN (from late last week) and MySQL. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Learning Django
I tripped on Django while looking for the best tool to re-implement a project. I'm not the one writing the code and for a number of reasons, Rails was picked for that project. But, in the process, I realized where Django was the clear winner. On our project list now is re-implementing some sites that are currently done in Drupal using Django. That said, I have read the tutorial and dabbled a bit to understand what Django is and what it can do. I seem to have ended up at "the tutorial is easy but now what"? That is, the concepts seemed to fit fine but attacking a new project made my head hurt. I grabbed the miniblog software from http://groups.google.com/group/django-users/browse_thread/thread/d8ae2e3dc533e214/75d2281e490f1d83 that was recently mentioned, got it running and kept thinking about all the additional things I could add. Now, I realize I still don't have time yet but it was a very different feeling from my previous tinkering experiences. What I am suggesting is that Django growth would benefit from a tutorial that starts with "something that works" that you can play with to understand the basics and can expand as you gain confidence and knowledge. I am clearly not ready to write this nor do I currently have the time but if somone is interested in taking this concept further, I would be happy to work with them. We could probably even turn it into a series of web articles for the Linux Journal site if the potential of making a bit of money is appealing. :-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Learning Django
Adrian Holovaty wrote: ... If you have any > questions, I'd encourage you to ask them; people on this mailing list > are super-nice and helpful! > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com I have to agree completely here. I see so much knowledge being distributed. I am sure you will see questions from me and/or other SSC people when we get to the Drupal to Django work. I tend to at least skim this list every day and continually see "important bits of wisdom". A lot of it becomes "gee, that will be important when we get working" or "I don't want to make that mistake". That, unfortunately, raises the issue of how to find that wisdom when you actually need it. I continually have this problem with another web site I did (nicaliving.com) and keep wanting to come up with an answer. While the answer isn't Django-unique, the high level of good information on this list makes me want to find an answer. It is an interesting question to me--probably because of being in the publishing business anyway--because there is so much good information on the Django web site itself and allowing comments augments the relatively static content but there is still so much more here. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Override value on save in admin
Just entering data in the admin interface. I want to stuck the current user in a field at save time if nothing has been specified. I understand needing to define a new save method and calling the "real one" in the model. But, do I have access to who someone is currently logged in as? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
