How To Create A Form With Generic Relations In Django
Hi, How can I create a Form with normal form elements and generic elements together as ModelForm For using frontend CRUD. For example; Generic Model: class Todo(models.Model): user = models.ForeignKey(User, related_name="todo") title = models.CharField(max_length=100, unique=False) slug = models.SlugField(max_length=50) completed = models.BooleanField() created_at = models.DateTimeField(auto_now_add=True) updated_at = models.DateTimeField(auto_now_add=True) content_type = models.ForeignKey(ContentType, related_name="todos") object_id = models.PositiveIntegerField() content_object = generic.GenericForeignKey() And other model: class Project(models.Model): user = models.ForeignKey(User, related_name="project") title = models.CharField(max_length=255, unique=True) slug = models.SlugField(max_length=50) description = models.TextField() active = models.BooleanField() created_at = models.DateTimeField(auto_now_add=True) updated_at = models.DateTimeField(auto_now_add=True) # Generic relation with Todo model todo = generic.GenericRelation(Todo) Forms: Created a formset for making Todo inline for Project and passed formset to form template. But its not merged with ProjectForm when render form. from django.contrib.contenttypes.generic import generic_inlineformset_factory TodoFormSet = generic_inlineformset_factory(Todo, extra=1) formset = TodoFormSet(instance=Project()) Now if I create a ModelForm, for project: (project/create urlpattern, with this i can get ProjectForm to produce form) for todo: (project/todo/create urlpattern, with this i can get TodoForm to produce todo) How to i do ProjectForm inline TodoForm form? and produce new ProjectForm? Thanks. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Something.is_live instead of implementation specific is_live settings
I read that article. The problem is that it's deployment specific. I dint even know what host name "omh.cc" is, but I have a feeling that you couldn't work on that from your laptop to your desktop without changing something. What I propose isn't a is_production variable. I'm proposing an explicit is_development variable so that I can choose my settings "explicitly" instead of trying to import something and then something else if that's not there. That is very un-pythonic. If I can say something to the effect of: if project.is_dev: import dev_settings else: # is live just example. I'm not suggesting "project" as a global. It's just to show the type of setting I want. That's much cleaner, and far more explicit than "import os, socket, etc". On Sep 23, 7:41 pm, Yo-Yo Ma wrote: > Thanks for the link David. I'm gonna check it it now. > > On Sep 23, 6:16 pm, "David P. Novakovic" > wrote: > > > > > This link and the comments suggest some good stuff... particularly the > > comment from Malcolm and the original post. > > >http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-p... > > > On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic > > > wrote: > > > The thing is, in production mode you normally have to define where > > > your settings are anyway, so you pass the unusual settings file name > > > there, and just use the regular settings.py for your development. > > > > So then you are passing the settings configuration information once in > > > the production server's configuration, not every time you run your > > > development server. > > > > I think people with any decent sized project have addressed this issue > > > in their own way that suits their own needs. > > > > For example we have lots of settings files and just import the > > > relevant settings into a final file. > > > > For testing I do what i mentioned in my previous email. > > > > Like anything on here, you need to ask whether what you are suggesting > > > would actually be better off as part of the core or if it works just > > > fine as something that people can choose to use themselves... > > > > I think most people use whatever system they are happy with and it > > > doesn't get in the way of deployment/development. Thus this fails to > > > meet one of the critical requirements for consideration for inclusion > > > into core. > > > > D > > > > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma > > > wrote: > > >> Thanks David, but I'm talking about having something built in. For > > >> instance, passing a variable to the "Development" server to tell it > > >> you're in "Development" seems a bit redundant, no? > > > >> On Sep 23, 3:39 pm, "David P. Novakovic" > > >> wrote: > > >>> As for running different configs: > > > >>> manage.py runserver --settings=settings_test > > > >>> etc.. > > > >>> On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss > > >>> wrote: > > >>> > On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma > > >>> > wrote: > > >>> >> I'm simply proposing the idea of having the development server > > >>> >> explicitly set something to indicate a "in development" status, so > > >>> >> that if that does not exist you can make the assumption that the > > >>> >> project is live. > > > >>> > This is exactly what the settings.DEBUG flag is for. Use it. Love it. > > > >>> > Jacob > > > >>> > -- > > >>> > You received this message because you are subscribed to the Google > > >>> > Groups "Django developers" group. > > >>> > To post to this group, send email to > > >>> > django-develop...@googlegroups.com. > > >>> > To unsubscribe from this group, send email to > > >>> > django-developers+unsubscr...@googlegroups.com. > > >>> > For more options, visit this group > > >>> > athttp://groups.google.com/group/django-developers?hl=en. > > > >> -- > > >> You received this message because you are subscribed to the Google > > >> Groups "Django developers" group. > > >> To post to this group, send email to django-develop...@googlegroups.com. > > >> To unsubscribe from this group, send email to > > >> django-developers+unsubscr...@googlegroups.com. > > >> For more options, visit this group > > >> athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Something.is_live instead of implementation specific is_live settings
How it's better from both of the following: 1) try: from dev_settings import * except ImportError: pass 2) if DEBUG: from dev_settings import * Because to have "project.is_dev" you'll have to write it somewhere already! It's bootstrapping problem. On Sat, Sep 25, 2010 at 12:01 AM, Yo-Yo Ma wrote: > I read that article. The problem is that it's deployment specific. I > dint even know what host name "omh.cc" is, but I have a feeling that > you couldn't work on that from your laptop to your desktop without > changing something. What I propose isn't a is_production variable. I'm > proposing an explicit is_development variable so that I can choose my > settings "explicitly" instead of trying to import something and then > something else if that's not there. That is very un-pythonic. If I can > say something to the effect of: > > if project.is_dev: > import dev_settings > else: > # is live > > just example. I'm not suggesting "project" as a global. It's just to > show the type of setting I want. > > That's much cleaner, and far more explicit than "import os, socket, > etc". > > > On Sep 23, 7:41 pm, Yo-Yo Ma wrote: >> Thanks for the link David. I'm gonna check it it now. >> >> On Sep 23, 6:16 pm, "David P. Novakovic" >> wrote: >> >> >> >> > This link and the comments suggest some good stuff... particularly the >> > comment from Malcolm and the original post. >> >> >http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-p... >> >> > On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic >> >> > wrote: >> > > The thing is, in production mode you normally have to define where >> > > your settings are anyway, so you pass the unusual settings file name >> > > there, and just use the regular settings.py for your development. >> >> > > So then you are passing the settings configuration information once in >> > > the production server's configuration, not every time you run your >> > > development server. >> >> > > I think people with any decent sized project have addressed this issue >> > > in their own way that suits their own needs. >> >> > > For example we have lots of settings files and just import the >> > > relevant settings into a final file. >> >> > > For testing I do what i mentioned in my previous email. >> >> > > Like anything on here, you need to ask whether what you are suggesting >> > > would actually be better off as part of the core or if it works just >> > > fine as something that people can choose to use themselves... >> >> > > I think most people use whatever system they are happy with and it >> > > doesn't get in the way of deployment/development. Thus this fails to >> > > meet one of the critical requirements for consideration for inclusion >> > > into core. >> >> > > D >> >> > > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma >> > > wrote: >> > >> Thanks David, but I'm talking about having something built in. For >> > >> instance, passing a variable to the "Development" server to tell it >> > >> you're in "Development" seems a bit redundant, no? >> >> > >> On Sep 23, 3:39 pm, "David P. Novakovic" >> > >> wrote: >> > >>> As for running different configs: >> >> > >>> manage.py runserver --settings=settings_test >> >> > >>> etc.. >> >> > >>> On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss >> > >>> wrote: >> > >>> > On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma >> > >>> > wrote: >> > >>> >> I'm simply proposing the idea of having the development server >> > >>> >> explicitly set something to indicate a "in development" status, so >> > >>> >> that if that does not exist you can make the assumption that the >> > >>> >> project is live. >> >> > >>> > This is exactly what the settings.DEBUG flag is for. Use it. Love it. >> >> > >>> > Jacob >> >> > >>> > -- >> > >>> > You received this message because you are subscribed to the Google >> > >>> > Groups "Django developers" group. >> > >>> > To post to this group, send email to >> > >>> > django-develop...@googlegroups.com. >> > >>> > To unsubscribe from this group, send email to >> > >>> > django-developers+unsubscr...@googlegroups.com. >> > >>> > For more options, visit this group >> > >>> > athttp://groups.google.com/group/django-developers?hl=en. >> >> > >> -- >> > >> You received this message because you are subscribed to the Google >> > >> Groups "Django developers" group. >> > >> To post to this group, send email to django-develop...@googlegroups.com. >> > >> To unsubscribe from this group, send email to >> > >> django-developers+unsubscr...@googlegroups.com. >> > >> For more options, visit this group >> > >> athttp://groups.google.com/group/django-developers?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.googl
Re: How To Create A Form With Generic Relations In Django
SuperForm(ProjectForm, TodoForm): pass #stuff peace, Ryan McIntosh Software Architect PeaceWorks Computer Consulting ph: (204) 480-0314 cell: (204) 770-3682 r...@peaceworks.ca - Original Message - From: "Harry" To: "Django developers" Sent: Friday, 24 September, 2010 10:17:02 GMT -06:00 US/Canada Central Subject: How To Create A Form With Generic Relations In Django Hi, How can I create a Form with normal form elements and generic elements together as ModelForm For using frontend CRUD. For example; Generic Model: class Todo(models.Model): user = models.ForeignKey(User, related_name="todo") title = models.CharField(max_length=100, unique=False) slug = models.SlugField(max_length=50) completed = models.BooleanField() created_at = models.DateTimeField(auto_now_add=True) updated_at = models.DateTimeField(auto_now_add=True) content_type = models.ForeignKey(ContentType, related_name="todos") object_id = models.PositiveIntegerField() content_object = generic.GenericForeignKey() And other model: class Project(models.Model): user = models.ForeignKey(User, related_name="project") title = models.CharField(max_length=255, unique=True) slug = models.SlugField(max_length=50) description = models.TextField() active = models.BooleanField() created_at = models.DateTimeField(auto_now_add=True) updated_at = models.DateTimeField(auto_now_add=True) # Generic relation with Todo model todo = generic.GenericRelation(Todo) Forms: Created a formset for making Todo inline for Project and passed formset to form template. But its not merged with ProjectForm when render form. from django.contrib.contenttypes.generic import generic_inlineformset_factory TodoFormSet = generic_inlineformset_factory(Todo, extra=1) formset = TodoFormSet(instance=Project()) Now if I create a ModelForm, for project: (project/create urlpattern, with this i can get ProjectForm to produce form) for todo: (project/todo/create urlpattern, with this i can get TodoForm to produce todo) How to i do ProjectForm inline TodoForm form? and produce new ProjectForm? Thanks. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Something.is_live instead of implementation specific is_live settings
Forgive the slight tangent, but I think it's important to understand why settings are defined in Python and not a markup language (like some RoR settings are). It's a very intentional design decision that gives developers the flexibility to define settings in a way that makes the most sense for their project (with the help of a programming language). That is *powerful*. It means that: - If you want to store settings in a markup language, all you have to do is write an adapter. - If you want to put settings in a database, you can do that too (but you're probably doing it wrong). - Or, as most people do, you can define them in pure Python. However, that flexibility isn't solely restricted to the method of defining settings; it could also be applied in the selective determination and loading of settings. Now, consider the problem you're trying to solve. It will work great on simple sites that have one development server and one production server. However, if it is implemented we would be forcing a specific server setup and workflow on Django's users, and not all Django projects are deployed in the same way. What if you also having a staging server that QA checks are made on? What if you have 3 production servers that are load balanced, each of which are optimized in different ways and thus require different settings? Django's settings are able to accommodate edge cases like this because they are generic and flexible. You have the power to (and should!) find a solution that makes sense for your project, as it seems you've done. However, that sort of thing belongs in a project, not in Django itself. On Fri, Sep 24, 2010 at 1:01 PM, Yo-Yo Ma wrote: > I read that article. The problem is that it's deployment specific. I > dint even know what host name "omh.cc" is, but I have a feeling that > you couldn't work on that from your laptop to your desktop without > changing something. What I propose isn't a is_production variable. I'm > proposing an explicit is_development variable so that I can choose my > settings "explicitly" instead of trying to import something and then > something else if that's not there. That is very un-pythonic. If I can > say something to the effect of: > > if project.is_dev: >import dev_settings > else: ># is live > > just example. I'm not suggesting "project" as a global. It's just to > show the type of setting I want. > > That's much cleaner, and far more explicit than "import os, socket, > etc". > > > On Sep 23, 7:41 pm, Yo-Yo Ma wrote: > > Thanks for the link David. I'm gonna check it it now. > > > > On Sep 23, 6:16 pm, "David P. Novakovic" > > wrote: > > > > > > > > > This link and the comments suggest some good stuff... particularly the > > > comment from Malcolm and the original post. > > > > >http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-p. > .. > > > > > On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic > > > > > wrote: > > > > The thing is, in production mode you normally have to define where > > > > your settings are anyway, so you pass the unusual settings file name > > > > there, and just use the regular settings.py for your development. > > > > > > So then you are passing the settings configuration information once > in > > > > the production server's configuration, not every time you run your > > > > development server. > > > > > > I think people with any decent sized project have addressed this > issue > > > > in their own way that suits their own needs. > > > > > > For example we have lots of settings files and just import the > > > > relevant settings into a final file. > > > > > > For testing I do what i mentioned in my previous email. > > > > > > Like anything on here, you need to ask whether what you are > suggesting > > > > would actually be better off as part of the core or if it works just > > > > fine as something that people can choose to use themselves... > > > > > > I think most people use whatever system they are happy with and it > > > > doesn't get in the way of deployment/development. Thus this fails to > > > > meet one of the critical requirements for consideration for inclusion > > > > into core. > > > > > > D > > > > > > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma > wrote: > > > >> Thanks David, but I'm talking about having something built in. For > > > >> instance, passing a variable to the "Development" server to tell it > > > >> you're in "Development" seems a bit redundant, no? > > > > > >> On Sep 23, 3:39 pm, "David P. Novakovic" > > > >> wrote: > > > >>> As for running different configs: > > > > > >>> manage.py runserver --settings=settings_test > > > > > >>> etc.. > > > > > >>> On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss < > ja...@jacobian.org> wrote: > > > >>> > On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma < > baxterstock...@gmail.com> wrote: > > > >>> >> I'm simply proposing the idea of having the development server > > > >>> >> explicitly set something to indicate a "in development" sta
Re: Something.is_live instead of implementation specific is_live settings
What if I want dev settings in version control? What if I want "explicit"? On Sep 24, 11:09 am, "burc...@gmail.com" wrote: > How it's better from both of the following: > > 1) > try: > from dev_settings import * > except ImportError: > pass > > 2) > if DEBUG: > from dev_settings import * > > Because to have "project.is_dev" you'll have to write it somewhere already! > > It's bootstrapping problem. > > > > > > On Sat, Sep 25, 2010 at 12:01 AM, Yo-Yo Ma wrote: > > I read that article. The problem is that it's deployment specific. I > > dint even know what host name "omh.cc" is, but I have a feeling that > > you couldn't work on that from your laptop to your desktop without > > changing something. What I propose isn't a is_production variable. I'm > > proposing an explicit is_development variable so that I can choose my > > settings "explicitly" instead of trying to import something and then > > something else if that's not there. That is very un-pythonic. If I can > > say something to the effect of: > > > if project.is_dev: > > import dev_settings > > else: > > # is live > > > just example. I'm not suggesting "project" as a global. It's just to > > show the type of setting I want. > > > That's much cleaner, and far more explicit than "import os, socket, > > etc". > > > On Sep 23, 7:41 pm, Yo-Yo Ma wrote: > >> Thanks for the link David. I'm gonna check it it now. > > >> On Sep 23, 6:16 pm, "David P. Novakovic" > >> wrote: > > >> > This link and the comments suggest some good stuff... particularly the > >> > comment from Malcolm and the original post. > > >> >http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-p... > > >> > On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic > > >> > wrote: > >> > > The thing is, in production mode you normally have to define where > >> > > your settings are anyway, so you pass the unusual settings file name > >> > > there, and just use the regular settings.py for your development. > > >> > > So then you are passing the settings configuration information once in > >> > > the production server's configuration, not every time you run your > >> > > development server. > > >> > > I think people with any decent sized project have addressed this issue > >> > > in their own way that suits their own needs. > > >> > > For example we have lots of settings files and just import the > >> > > relevant settings into a final file. > > >> > > For testing I do what i mentioned in my previous email. > > >> > > Like anything on here, you need to ask whether what you are suggesting > >> > > would actually be better off as part of the core or if it works just > >> > > fine as something that people can choose to use themselves... > > >> > > I think most people use whatever system they are happy with and it > >> > > doesn't get in the way of deployment/development. Thus this fails to > >> > > meet one of the critical requirements for consideration for inclusion > >> > > into core. > > >> > > D > > >> > > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma > >> > > wrote: > >> > >> Thanks David, but I'm talking about having something built in. For > >> > >> instance, passing a variable to the "Development" server to tell it > >> > >> you're in "Development" seems a bit redundant, no? > > >> > >> On Sep 23, 3:39 pm, "David P. Novakovic" > >> > >> wrote: > >> > >>> As for running different configs: > > >> > >>> manage.py runserver --settings=settings_test > > >> > >>> etc.. > > >> > >>> On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss > >> > >>> wrote: > >> > >>> > On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma > >> > >>> > wrote: > >> > >>> >> I'm simply proposing the idea of having the development server > >> > >>> >> explicitly set something to indicate a "in development" status, so > >> > >>> >> that if that does not exist you can make the assumption that the > >> > >>> >> project is live. > > >> > >>> > This is exactly what the settings.DEBUG flag is for. Use it. Love > >> > >>> > it. > > >> > >>> > Jacob > > >> > >>> > -- > >> > >>> > You received this message because you are subscribed to the Google > >> > >>> > Groups "Django developers" group. > >> > >>> > To post to this group, send email to > >> > >>> > django-develop...@googlegroups.com. > >> > >>> > To unsubscribe from this group, send email to > >> > >>> > django-developers+unsubscr...@googlegroups.com. > >> > >>> > For more options, visit this group > >> > >>> > athttp://groups.google.com/group/django-developers?hl=en. > > >> > >> -- > >> > >> You received this message because you are subscribed to the Google > >> > >> Groups "Django developers" group. > >> > >> To post to this group, send email to > >> > >> django-develop...@googlegroups.com. > >> > >> To unsubscribe from this group, send email to > >> > >> django-developers+unsubscr...@googlegroups.com. > >> > >> For more options, visit this group > >> > >> athttp://groups.google.com/group/django-developers?hl=en. > > > -- > > You received
Re: Something.is_live instead of implementation specific is_live settings
On Sat, Sep 25, 2010 at 12:46 AM, Chuck Harmston wrote: > their project (with the help of a programming language). That is powerful. ...But is not very practical for 90% of django users, who have to invent their own bikes. > However, that flexibility isn't solely restricted to the method of defining > settings; it could also be applied in the selective determination and > loading of settings. Now, consider the problem you're trying to solve. It > will work great on simple sites that have one development server and one > production server. However, if it is implemented we would be forcing a > specific server setup and workflow on Django's users, and not all Django > projects are deployed in the same way. Why everyone talking about improvement of settings insists on forcing anything and forgets about "backends" way completely? > Django's settings are able to accommodate edge cases like this because they > are generic and flexible. I think you are mistaken here. Writing sites with Python is more flexible than with Django, so why people are using Django? Everyone prefers fine-grained framework to powerful command line and missing libraries! Django settings are kept *simple*, not *powerful*. Backends that support different ways of configurations is what is *powerful*. > You have the power to (and should!) find a solution that makes sense for your > project, as it seems you've done. > However, that sort of thing belongs in a project, not in Django itself. And not everyone agrees on that decision! > On Fri, Sep 24, 2010 at 1:01 PM, Yo-Yo Ma wrote: >> >> I read that article. The problem is that it's deployment specific. I >> dint even know what host name "omh.cc" is, but I have a feeling that >> you couldn't work on that from your laptop to your desktop without >> changing something. What I propose isn't a is_production variable. I'm >> proposing an explicit is_development variable so that I can choose my >> settings "explicitly" instead of trying to import something and then >> something else if that's not there. That is very un-pythonic. If I can >> say something to the effect of: >> >> if project.is_dev: >> import dev_settings >> else: >> # is live >> >> just example. I'm not suggesting "project" as a global. It's just to >> show the type of setting I want. >> >> That's much cleaner, and far more explicit than "import os, socket, >> etc". >> >> >> On Sep 23, 7:41 pm, Yo-Yo Ma wrote: >> > Thanks for the link David. I'm gonna check it it now. >> > >> > On Sep 23, 6:16 pm, "David P. Novakovic" >> > wrote: >> > >> > >> > >> > > This link and the comments suggest some good stuff... particularly the >> > > comment from Malcolm and the original post. >> > >> > >> > > >http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-p... >> > >> > > On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic >> > >> > > wrote: >> > > > The thing is, in production mode you normally have to define where >> > > > your settings are anyway, so you pass the unusual settings file name >> > > > there, and just use the regular settings.py for your development. >> > >> > > > So then you are passing the settings configuration information once >> > > > in >> > > > the production server's configuration, not every time you run your >> > > > development server. >> > >> > > > I think people with any decent sized project have addressed this >> > > > issue >> > > > in their own way that suits their own needs. >> > >> > > > For example we have lots of settings files and just import the >> > > > relevant settings into a final file. >> > >> > > > For testing I do what i mentioned in my previous email. >> > >> > > > Like anything on here, you need to ask whether what you are >> > > > suggesting >> > > > would actually be better off as part of the core or if it works just >> > > > fine as something that people can choose to use themselves... >> > >> > > > I think most people use whatever system they are happy with and it >> > > > doesn't get in the way of deployment/development. Thus this fails to >> > > > meet one of the critical requirements for consideration for >> > > > inclusion >> > > > into core. >> > >> > > > D >> > >> > > > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma >> > > > wrote: >> > > >> Thanks David, but I'm talking about having something built in. For >> > > >> instance, passing a variable to the "Development" server to tell it >> > > >> you're in "Development" seems a bit redundant, no? >> > >> > > >> On Sep 23, 3:39 pm, "David P. Novakovic" >> > > >> wrote: >> > > >>> As for running different configs: >> > >> > > >>> manage.py runserver --settings=settings_test >> > >> > > >>> etc.. >> > >> > > >>> On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss >> > > >>> wrote: >> > > >>> > On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma >> > > >>> > wrote: >> > > >>> >> I'm simply proposing the idea of having the development server >> > > >>> >> explicitly set something to indicate a "in development" status, >> > > >>> >> so >
Re: Something.is_live instead of implementation specific is_live settings
If everything is under version control, you'll need to detect the server status somehow. Some options: - check the absolute path of the settings file on the filesystem if you can ensure this path is different on the production server - import socket; and check socket.gethostname() - check for "runserver" in sys.argv - etc. On 25 September 2010 06:50, Yo-Yo Ma wrote: > > What if I want dev settings in version control? > > What if I want "explicit"? > > > On Sep 24, 11:09 am, "burc...@gmail.com" wrote: > > How it's better from both of the following: > > > > 1) > > try: > > from dev_settings import * > > except ImportError: > >pass > > > > 2) > > if DEBUG: > > from dev_settings import * > > > > Because to have "project.is_dev" you'll have to write it somewhere > already! > > > > It's bootstrapping problem. > > > > > > > > > > > > On Sat, Sep 25, 2010 at 12:01 AM, Yo-Yo Ma > wrote: > > > I read that article. The problem is that it's deployment specific. I > > > dint even know what host name "omh.cc" is, but I have a feeling that > > > you couldn't work on that from your laptop to your desktop without > > > changing something. What I propose isn't a is_production variable. I'm > > > proposing an explicit is_development variable so that I can choose my > > > settings "explicitly" instead of trying to import something and then > > > something else if that's not there. That is very un-pythonic. If I can > > > say something to the effect of: > > > > > if project.is_dev: > > >import dev_settings > > > else: > > ># is live > > > > > just example. I'm not suggesting "project" as a global. It's just to > > > show the type of setting I want. > > > > > That's much cleaner, and far more explicit than "import os, socket, > > > etc". > > > > > On Sep 23, 7:41 pm, Yo-Yo Ma wrote: > > >> Thanks for the link David. I'm gonna check it it now. > > > > >> On Sep 23, 6:16 pm, "David P. Novakovic" > > >> wrote: > > > > >> > This link and the comments suggest some good stuff... particularly > the > > >> > comment from Malcolm and the original post. > > > > >> > > http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-p... > > > > >> > On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic > > > > >> > wrote: > > >> > > The thing is, in production mode you normally have to define where > > >> > > your settings are anyway, so you pass the unusual settings file > name > > >> > > there, and just use the regular settings.py for your development. > > > > >> > > So then you are passing the settings configuration information > once in > > >> > > the production server's configuration, not every time you run your > > >> > > development server. > > > > >> > > I think people with any decent sized project have addressed this > issue > > >> > > in their own way that suits their own needs. > > > > >> > > For example we have lots of settings files and just import the > > >> > > relevant settings into a final file. > > > > >> > > For testing I do what i mentioned in my previous email. > > > > >> > > Like anything on here, you need to ask whether what you are > suggesting > > >> > > would actually be better off as part of the core or if it works > just > > >> > > fine as something that people can choose to use themselves... > > > > >> > > I think most people use whatever system they are happy with and it > > >> > > doesn't get in the way of deployment/development. Thus this fails > to > > >> > > meet one of the critical requirements for consideration for > inclusion > > >> > > into core. > > > > >> > > D > > > > >> > > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma < > baxterstock...@gmail.com> wrote: > > >> > >> Thanks David, but I'm talking about having something built in. > For > > >> > >> instance, passing a variable to the "Development" server to tell > it > > >> > >> you're in "Development" seems a bit redundant, no? > > > > >> > >> On Sep 23, 3:39 pm, "David P. Novakovic" < > davidnovako...@gmail.com> > > >> > >> wrote: > > >> > >>> As for running different configs: > > > > >> > >>> manage.py runserver --settings=settings_test > > > > >> > >>> etc.. > > > > >> > >>> On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss < > ja...@jacobian.org> wrote: > > >> > >>> > On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma < > baxterstock...@gmail.com> wrote: > > >> > >>> >> I'm simply proposing the idea of having the development > server > > >> > >>> >> explicitly set something to indicate a "in development" > status, so > > >> > >>> >> that if that does not exist you can make the assumption that > the > > >> > >>> >> project is live. > > > > >> > >>> > This is exactly what the settings.DEBUG flag is for. Use it. > Love it. > > > > >> > >>> > Jacob > > > > >> > >>> > -- > > >> > >>> > You received this message because you are subscribed to the > Google Groups "Django developers" group. > > >> > >>> > To post to this group, send email to > django-develop...@googlegroups.com. > > >> > >>> > To unsubscribe from this group, send emai
Re: Something.is_live instead of implementation specific is_live settings
On Sat, Sep 25, 2010 at 3:50 AM, Yo-Yo Ma wrote: > > What if I want dev settings in version control? Please write in details. Do you have single development configuration or multiple? Single development PC or multiple? > What if I want "explicit"? Aren't they explicit enough? Ok, version 3. settings.py (in version control): -->8 if DEBUG: KEY1 = 'value1' KEY2 = 'value2' else: KEY3 = 'value3' Is that now what you want? > On Sep 24, 11:09 am, "burc...@gmail.com" wrote: >> How it's better from both of the following: >> >> 1) >> try: >> from dev_settings import * >> except ImportError: >> pass >> >> 2) >> if DEBUG: >> from dev_settings import * >> >> Because to have "project.is_dev" you'll have to write it somewhere already! >> >> It's bootstrapping problem. >> >> >> >> >> >> On Sat, Sep 25, 2010 at 12:01 AM, Yo-Yo Ma wrote: >> > I read that article. The problem is that it's deployment specific. I >> > dint even know what host name "omh.cc" is, but I have a feeling that >> > you couldn't work on that from your laptop to your desktop without >> > changing something. What I propose isn't a is_production variable. I'm >> > proposing an explicit is_development variable so that I can choose my >> > settings "explicitly" instead of trying to import something and then >> > something else if that's not there. That is very un-pythonic. If I can >> > say something to the effect of: >> >> > if project.is_dev: >> > import dev_settings >> > else: >> > # is live >> >> > just example. I'm not suggesting "project" as a global. It's just to >> > show the type of setting I want. >> >> > That's much cleaner, and far more explicit than "import os, socket, >> > etc". >> >> > On Sep 23, 7:41 pm, Yo-Yo Ma wrote: >> >> Thanks for the link David. I'm gonna check it it now. >> >> >> On Sep 23, 6:16 pm, "David P. Novakovic" >> >> wrote: >> >> >> > This link and the comments suggest some good stuff... particularly the >> >> > comment from Malcolm and the original post. >> >> >> >http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-p... >> >> >> > On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic >> >> >> > wrote: >> >> > > The thing is, in production mode you normally have to define where >> >> > > your settings are anyway, so you pass the unusual settings file name >> >> > > there, and just use the regular settings.py for your development. >> >> >> > > So then you are passing the settings configuration information once in >> >> > > the production server's configuration, not every time you run your >> >> > > development server. >> >> >> > > I think people with any decent sized project have addressed this issue >> >> > > in their own way that suits their own needs. >> >> >> > > For example we have lots of settings files and just import the >> >> > > relevant settings into a final file. >> >> >> > > For testing I do what i mentioned in my previous email. >> >> >> > > Like anything on here, you need to ask whether what you are suggesting >> >> > > would actually be better off as part of the core or if it works just >> >> > > fine as something that people can choose to use themselves... >> >> >> > > I think most people use whatever system they are happy with and it >> >> > > doesn't get in the way of deployment/development. Thus this fails to >> >> > > meet one of the critical requirements for consideration for inclusion >> >> > > into core. >> >> >> > > D >> >> >> > > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma >> >> > > wrote: >> >> > >> Thanks David, but I'm talking about having something built in. For >> >> > >> instance, passing a variable to the "Development" server to tell it >> >> > >> you're in "Development" seems a bit redundant, no? >> >> >> > >> On Sep 23, 3:39 pm, "David P. Novakovic" >> >> > >> wrote: >> >> > >>> As for running different configs: >> >> >> > >>> manage.py runserver --settings=settings_test >> >> >> > >>> etc.. >> >> >> > >>> On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss >> >> > >>> wrote: >> >> > >>> > On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma >> >> > >>> > wrote: >> >> > >>> >> I'm simply proposing the idea of having the development server >> >> > >>> >> explicitly set something to indicate a "in development" status, >> >> > >>> >> so >> >> > >>> >> that if that does not exist you can make the assumption that the >> >> > >>> >> project is live. >> >> >> > >>> > This is exactly what the settings.DEBUG flag is for. Use it. Love >> >> > >>> > it. >> >> >> > >>> > Jacob >> >> >> > >>> > -- >> >> > >>> > You received this message because you are subscribed to the >> >> > >>> > Google Groups "Django developers" group. >> >> > >>> > To post to this group, send email to >> >> > >>> > django-develop...@googlegroups.com. >> >> > >>> > To unsubscribe from this group, send email to >> >> > >>> > django-developers+unsubscr...@googlegroups.com. >> >> > >>> > For more options, visit this group >> >> > >>> > athtt
Re: Something.is_live instead of implementation specific is_live settings
On Fri, Sep 24, 2010 at 3:50 PM, Yo-Yo Ma wrote: > > What if I want dev settings in version control? > > What if I want "explicit"? At this point this discussion is getting pretty far off-topic; can you please take it to django-users? Thanks, Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Something.is_live instead of implementation specific is_live settings
My technique, which allows you to: - Segregate settings per environment - Keep environmental settings under version control - Have multiple environments on a single host (using an environment variable set by the WSGI script) - Keep passwords and other sensitive information out of source control - Conditionally modify settings based on the value of settings.DEBUG https://gist.github.com/5e0e3d58e92f7530b396 Feel free to steal/modify/improve as you wish. At this point, I think we're veering into django-users territory. Let's bring it over there unless someone still feels strongly about Yo-Yo Ma's original suggestion. On Fri, Sep 24, 2010 at 4:58 PM, Simon Meers wrote: > If everything is under version control, you'll need to detect the server > status somehow. Some options: > - check the absolute path of the settings file on the filesystem if you can > ensure this path is different on the production server > - import socket; and check socket.gethostname() > - check for "runserver" in sys.argv > - etc. > > > On 25 September 2010 06:50, Yo-Yo Ma wrote: > >> >> What if I want dev settings in version control? >> >> What if I want "explicit"? >> >> >> On Sep 24, 11:09 am, "burc...@gmail.com" wrote: >> > How it's better from both of the following: >> > >> > 1) >> > try: >> > from dev_settings import * >> > except ImportError: >> >pass >> > >> > 2) >> > if DEBUG: >> > from dev_settings import * >> > >> > Because to have "project.is_dev" you'll have to write it somewhere >> already! >> > >> > It's bootstrapping problem. >> > >> > >> > >> > >> > >> > On Sat, Sep 25, 2010 at 12:01 AM, Yo-Yo Ma >> wrote: >> > > I read that article. The problem is that it's deployment specific. I >> > > dint even know what host name "omh.cc" is, but I have a feeling that >> > > you couldn't work on that from your laptop to your desktop without >> > > changing something. What I propose isn't a is_production variable. I'm >> > > proposing an explicit is_development variable so that I can choose my >> > > settings "explicitly" instead of trying to import something and then >> > > something else if that's not there. That is very un-pythonic. If I can >> > > say something to the effect of: >> > >> > > if project.is_dev: >> > >import dev_settings >> > > else: >> > ># is live >> > >> > > just example. I'm not suggesting "project" as a global. It's just to >> > > show the type of setting I want. >> > >> > > That's much cleaner, and far more explicit than "import os, socket, >> > > etc". >> > >> > > On Sep 23, 7:41 pm, Yo-Yo Ma wrote: >> > >> Thanks for the link David. I'm gonna check it it now. >> > >> > >> On Sep 23, 6:16 pm, "David P. Novakovic" >> > >> wrote: >> > >> > >> > This link and the comments suggest some good stuff... particularly >> the >> > >> > comment from Malcolm and the original post. >> > >> > >> > >> http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-p... >> > >> > >> > On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic >> > >> > >> > wrote: >> > >> > > The thing is, in production mode you normally have to define >> where >> > >> > > your settings are anyway, so you pass the unusual settings file >> name >> > >> > > there, and just use the regular settings.py for your development. >> > >> > >> > > So then you are passing the settings configuration information >> once in >> > >> > > the production server's configuration, not every time you run >> your >> > >> > > development server. >> > >> > >> > > I think people with any decent sized project have addressed this >> issue >> > >> > > in their own way that suits their own needs. >> > >> > >> > > For example we have lots of settings files and just import the >> > >> > > relevant settings into a final file. >> > >> > >> > > For testing I do what i mentioned in my previous email. >> > >> > >> > > Like anything on here, you need to ask whether what you are >> suggesting >> > >> > > would actually be better off as part of the core or if it works >> just >> > >> > > fine as something that people can choose to use themselves... >> > >> > >> > > I think most people use whatever system they are happy with and >> it >> > >> > > doesn't get in the way of deployment/development. Thus this fails >> to >> > >> > > meet one of the critical requirements for consideration for >> inclusion >> > >> > > into core. >> > >> > >> > > D >> > >> > >> > > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma < >> baxterstock...@gmail.com> wrote: >> > >> > >> Thanks David, but I'm talking about having something built in. >> For >> > >> > >> instance, passing a variable to the "Development" server to tell >> it >> > >> > >> you're in "Development" seems a bit redundant, no? >> > >> > >> > >> On Sep 23, 3:39 pm, "David P. Novakovic" < >> davidnovako...@gmail.com> >> > >> > >> wrote: >> > >> > >>> As for running different configs: >> > >> > >> > >>> manage.py runserver --settings=settings_test >> > >> > >> > >>> etc.. >> > >> > >> > >>> On Fri, Sep
Re: Something.is_live instead of implementation specific is_live settings
Chuck - Thanks. Perhaps there isn't such room for improvement on the topic. Jacob - It appears to me that you don't read things before you comment on them. That's two times in one post. Patience is a virtue, my friend. On Sep 24, 3:12 pm, Chuck Harmston wrote: > My technique, which allows you to: > > - Segregate settings per environment > - Keep environmental settings under version control > - Have multiple environments on a single host (using an environment > variable set by the WSGI script) > - Keep passwords and other sensitive information out of source control > - Conditionally modify settings based on the value of settings.DEBUG > > https://gist.github.com/5e0e3d58e92f7530b396 > > Feel free to steal/modify/improve as you wish. > > At this point, I think we're veering into django-users territory. Let's > bring it over there unless someone still feels strongly about Yo-Yo Ma's > original suggestion. > > On Fri, Sep 24, 2010 at 4:58 PM, Simon Meers wrote: > > If everything is under version control, you'll need to detect the server > > status somehow. Some options: > > - check the absolute path of the settings file on the filesystem if you can > > ensure this path is different on the production server > > - import socket; and check socket.gethostname() > > - check for "runserver" in sys.argv > > - etc. > > > On 25 September 2010 06:50, Yo-Yo Ma wrote: > > >> What if I want dev settings in version control? > > >> What if I want "explicit"? > > >> On Sep 24, 11:09 am, "burc...@gmail.com" wrote: > >> > How it's better from both of the following: > > >> > 1) > >> > try: > >> > from dev_settings import * > >> > except ImportError: > >> > pass > > >> > 2) > >> > if DEBUG: > >> > from dev_settings import * > > >> > Because to have "project.is_dev" you'll have to write it somewhere > >> already! > > >> > It's bootstrapping problem. > > >> > On Sat, Sep 25, 2010 at 12:01 AM, Yo-Yo Ma > >> wrote: > >> > > I read that article. The problem is that it's deployment specific. I > >> > > dint even know what host name "omh.cc" is, but I have a feeling that > >> > > you couldn't work on that from your laptop to your desktop without > >> > > changing something. What I propose isn't a is_production variable. I'm > >> > > proposing an explicit is_development variable so that I can choose my > >> > > settings "explicitly" instead of trying to import something and then > >> > > something else if that's not there. That is very un-pythonic. If I can > >> > > say something to the effect of: > > >> > > if project.is_dev: > >> > > import dev_settings > >> > > else: > >> > > # is live > > >> > > just example. I'm not suggesting "project" as a global. It's just to > >> > > show the type of setting I want. > > >> > > That's much cleaner, and far more explicit than "import os, socket, > >> > > etc". > > >> > > On Sep 23, 7:41 pm, Yo-Yo Ma wrote: > >> > >> Thanks for the link David. I'm gonna check it it now. > > >> > >> On Sep 23, 6:16 pm, "David P. Novakovic" > >> > >> wrote: > > >> > >> > This link and the comments suggest some good stuff... particularly > >> the > >> > >> > comment from Malcolm and the original post. > > >>http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-p... > > >> > >> > On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic > > >> > >> > wrote: > >> > >> > > The thing is, in production mode you normally have to define > >> where > >> > >> > > your settings are anyway, so you pass the unusual settings file > >> name > >> > >> > > there, and just use the regular settings.py for your development. > > >> > >> > > So then you are passing the settings configuration information > >> once in > >> > >> > > the production server's configuration, not every time you run > >> your > >> > >> > > development server. > > >> > >> > > I think people with any decent sized project have addressed this > >> issue > >> > >> > > in their own way that suits their own needs. > > >> > >> > > For example we have lots of settings files and just import the > >> > >> > > relevant settings into a final file. > > >> > >> > > For testing I do what i mentioned in my previous email. > > >> > >> > > Like anything on here, you need to ask whether what you are > >> suggesting > >> > >> > > would actually be better off as part of the core or if it works > >> just > >> > >> > > fine as something that people can choose to use themselves... > > >> > >> > > I think most people use whatever system they are happy with and > >> it > >> > >> > > doesn't get in the way of deployment/development. Thus this fails > >> to > >> > >> > > meet one of the critical requirements for consideration for > >> inclusion > >> > >> > > into core. > > >> > >> > > D > > >> > >> > > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma < > >> baxterstock...@gmail.com> wrote: > >> > >> > >> Thanks David, but I'm talking about having something built in. > >> For > >> > >> > >> instance, passing a variable to the "Development" server
Re: Something.is_live instead of implementation specific is_live settings
On Sat, Sep 25, 2010 at 8:59 AM, Yo-Yo Ma wrote: > Chuck - Thanks. Perhaps there isn't such room for improvement on the > topic. > > Jacob - It appears to me that you don't read things before you comment > on them. That's two times in one post. Patience is a virtue, my > friend. This conversation may have started as a "lets add an 'in development' setting". That was very quickly refuted by two members of the community (one BDFL, and one person that I work with) that told you pretty clearly that Django best practice already has at least 2 existing solutions that can do what you describe. The conversation has since devolved into a 'heres all the ways you could do it right now', and a bunch of people showing you the various ways that Django configurations can be used to achieve the goal you describe. Yes, patience is a virtue. However, in this case, your call for patience implies that we should have confidence that this is a productive, on-topic discussion that is leading to a clear design decision that can be implemented. I've re-read this thread, and I don't see any indication that this is what is happening. *You* may think that there is still a feature under discussion. The remainder of the people in this thread -- who, from a quick mental count of what experience I'm aware of, have almost 20 years of Django experience between them (A BDFL and core devs at 5 years each, plus a number of 2+ year veterans) -- are telling you that this "feature" isn't needed. At which point, it's an education activity, and better suited to django-users. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
#12012 Logging: request for comments
Hi all, I've just uploaded a first draft at a patch introducing logging into Django [1]. I'm calling for feedback on this patch. [1] http://code.djangoproject.com/attachment/ticket/12012/t12012-alpha1.diff This patch is heavily drawn from the work that Vinay Sajip has done in this area, but it also includes some significant changes to his most recent patches. The patch introduces two settings: LOGGING_CONFIG - a callable that should be used to configure the logging machinery LOGGING - the configuration data to pass to the configuration function. By default, LOGGING_CONFIG points to logging.config.dictConfig, which means that LOGGING should be a dict-style logging configuration (as introduce by Python 2.7). A copy of dictConfig is included in utils for backwards compatibility. However, by changing LOGGING_CONFIG, you could use any configuration scheme you like. In addition, a new convention is introduced. If a Django app includes a 'startup.py' as a sibling module to models.py, tests.py etc, then this module will be loaded *exactly once* during the startup of the app. It will be loaded *after* the settings have been initialized, but *before* models.py has been imported. The patch includes the changes to the new project settings.py to show what LOGGING would look like in practice. This logging configuration puts everything to console, except for errors in the request process, which are mailed to the admin. This means redirecting 500 errors to something other than your email box is now a 1 line configuration item. The patch also includes logging entries for everywhere in the code where a 4XX or 5XX error is raised. 4XX's are raised as warnings; 5XX's as errors. Lastly, there is a separate logger that logs, at the debug level, every SQL statement that is executed. If you add a handler for django.db.backends that catches the DEBUG level, you will get this output. There are no docs because I'm waiting for the design to be finalized before I start writing; there are no tests because this is something that is a little difficult to test. At this point, I'm calling for feedback, particularly on the following: * logging config as the last stage of settings loading. Is this the right place? Can anyone think of a better place? * The default logging configuration. Have I got the propagate/override options right for sensible defaults (both in global and new-project settings)? * The logging calls that have been introduced. Is this too much or too little? I'd rather err on the side of caution here (we can always add extra logging later), but I'd like suggestions on anything else people think should be logged. Also, are they logged at the right level (e.g., is a 404 a warning?). * The startup.py convention (and implementation). Is this necessary? Does it address (or not address) any other prominent "on startup" use cases? There's also a crossover here with Arthur's GSoC work; is the startup code sufficiently important that we need it anyway, or can we defer until the app refactor lands? So - have at it. I'm really excited by this; so let me know everywhere I've messed up so that we can get this into trunk. Russ %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
