Class-based view improvement idea
Hello Everyone, I have been using class-based views for sometime now, and I am running into an issue while subclassing CreateView, and think that this type of thing could be placed into Django somehow to make it easier to implement. Most multi-user websites connect models to a user by some means, so the posts they make or articles they add list them as the owner/poster of it. Assigning the object to the user when using class-based views at the moment is annoying to say the least: def form_valid(self, form): self.object = form.save(commit=False) self.object.user = self.request.user self.object.save() return super(ModelFormMixin, self).form_valid(form) This is what I currently do, and it looks messy and unorganized. I would like a way to easily assign additional data to the self.object without going through all this. You may notice that I am calling super() on ModelFormMixin, when this is a CreateView, well the super() of CreateView will attempt to re-create the self.object from a form.save(), and since I already created the object here, with no easy way to just pass self.object... Anyways, you get the idea. Perhaps a new overridable method that allows us to do something with an uncommitted object before it is saved. Here is a new form_valid I propose: class ModelFormMixin(...): def not_sure_of_naming(self): pass def form_valid(self, form): self.object = form.save(commit=False) self.not_sure_of_naming() self.object.save() return super(ModelFormMixin, self).form_valid(form) This will allow us developers using class-based views to easily perform tasks on a self.object before it is finally saved back into the database. The above implementation is just an example of what I would love to see in a future version of class-based views. Best Regards, Kevin Veroneau Python Diary http://www.pythondiary.com/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/qRIihOsXQDoJ. To post to this group, send email to django-developers@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: Class-based view improvement idea
Scratch this, I just noticed that the dev docs explain a lot more than the 1.3/1.4 docs do. Perhaps having this documentation in 1.3/1.4 as well, or at least mentioning there that the dev docs contain much more information. On Sunday, 11 November 2012 11:31:41 UTC-6, Kevin Veroneau wrote: > > Hello Everyone, > > I have been using class-based views for sometime now, and I am running > into an issue while subclassing CreateView, and think that this type of > thing could be placed into Django somehow to make it easier to implement. > > Most multi-user websites connect models to a user by some means, so the > posts they make or articles they add list them as the owner/poster of it. > Assigning the object to the user when using class-based views at the moment > is annoying to say the least: > > def form_valid(self, form): > self.object = form.save(commit=False) > self.object.user = self.request.user > self.object.save() > return super(ModelFormMixin, self).form_valid(form) > > This is what I currently do, and it looks messy and unorganized. I > would like a way to easily assign additional data to the self.object > without going through all this. You may notice that I am calling super() > on ModelFormMixin, when this is a CreateView, well the super() of > CreateView will attempt to re-create the self.object from a form.save(), > and since I already created the object here, with no easy way to just pass > self.object... Anyways, you get the idea. > > Perhaps a new overridable method that allows us to do something with an > uncommitted object before it is saved. Here is a new form_valid I propose: > > class ModelFormMixin(...): > def not_sure_of_naming(self): > pass > def form_valid(self, form): > self.object = form.save(commit=False) > self.not_sure_of_naming() > self.object.save() > return super(ModelFormMixin, self).form_valid(form) > > This will allow us developers using class-based views to easily perform > tasks on a self.object before it is finally saved back into the database. > The above implementation is just an example of what I would love to see in > a future version of class-based views. > > Best Regards, > Kevin Veroneau > Python Diary > http://www.pythondiary.com/ > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/BEMYcZT9jK0J. To post to this group, send email to django-developers@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.
Why doesn't DjangoProject.com downloads provide a Windows installer like web2py does?
I am posting this here as I feel it is related to the development of Django, since it is related to it's distribution to end-users. Something that web2py has provided for a long time is a nice Windows installer to help Windows users start using web2py right away with zero-effort, similar to how WAMP works for PHP developers on Windows. I believe, it would be most beneficial for the Django website to provide such an option. I bet most Windows users who hear about Django visit the website, but don't see a download link for their system. These users will either seek help on how to set it up or it will deter them from exploring Django further. The latter is what we, as a community do not want to see. We would like prospect developers to at least explore the development environment and see what it's all about before making the choice of not using it For a time, there was a project called InstantDjango, it wasn't very well known, but it did the job of containing a Python/Django installation into a single directory which was portable and be easily deleted or moved onto a USB drive. The project maintainer has since removed the website from existence, along with the tutorials and download links he provided. Fortunately, I retained a copy of this and now host it on my blog with an updated version of Django. With the guidance of the main Django developers, I would like to perfect a distributable Windows installer for the greater Django community. Perhaps starting with Django 1.5, the community can also provide an easy Windows installer for test driving Django on a Windows machine, and for local Windows development. I can volunteer to maintain this port, with guidance from the other developers on how to distribute it and package it. The goal of this is to provide Windows users with an option to test drive Python and Django with minimal knowledge and risks. Installing Python and Django in Windows does require a fair amount of work and command-line knowledge, which may scare some Windows users away from this great framework. Think of how easy WAMP is to install and use for PHP developers, I want Django to have this ease of use as well. Disclaimer: I am a full-time Debian Linux user, but have attempted to install Python/Django on Windows in the past. I can understand what some Windows users go through during this ordeal. Link to retained InstantDjango(for example purposes): http://www.pythondiary.com/blog/Apr.10,2012/instant-django-release-information.html I plan on updating this InstantDjango with Django 1.5, and using distribute over setuptools. Current Download count: 1461 Best Regards, Kevin Veroneau -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/V5uyrCzB9OcJ. To post to this group, send email to django-developers@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.
Epydoc failed to generate documentation for Django 1.5
Hello Django team, I was attempting to build documentation for Django 1.5, and it seems that Epydoc doesn't like something in the GIS contrib in the tests.py module. Here is the beginning of the error, see the attached text file for the full stacktrace: | In /home/kveroneau/django15-env/lib/python2.6/site-packages/django/contrib/gis/management/ | commands/inspectdb.py: | Import failed (but source code parsing was successful). | Error: ImproperlyConfigured: Requested setting DATABASES, but settings are not configured. |You must either define the environment variable DJANGO_SETTINGS_MODULE or call |settings.configure() before accessing settings. (line 1) | Error: Internal error during parsing (/home/kveroneau/django15-env/lib/python2.6/ site-packages/django/contrib/gis/tests/__init__.py, line 84): 'int' object is unsubscriptable I was able to successfully map out the generic class-based views with UML graphs too, you can see it live here: http://epydoc.pythondiary.com/generic-views/ It really shows the complexity behind some of the class-based views Django has. The next thing I wanted to attempt is to document the entire Django project using Epydoc to see how that would look. Seeing these UML graphs is memorizing and very educational for when working with Django. Is this Epydoc error related to Epydoc or something that Django shouldn't have done in it's source code? Best Regards, Kevin Veroneau -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out. Error: Internal error during parsing (/home/kveroneau/django15-env/lib/python2.6/ site-packages/django/contrib/gis/tests/__init__.py, line 84): 'int' object is unsubscriptable Traceback (most recent call last): File "/home/kveroneau/django15-env/bin/epydoc", line 13, in cli() File "/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/cli.py", line 965, in cli main(options, names) File "/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/cli.py", line 757, in main exclude_parse=exclude_parse) File "/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docbuilder.py", line 206, in build_doc_index doc_pairs = _get_docs_from_items(items, options) File "/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docbuilder.py", line 398, in _get_docs_from_items item, doc_pairs[-1], options, progress_estimator) File "/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docbuilder.py", line 602, in _get_docs_from_submodules subpackage_dir, docs[-1], options, progress_estimator) File "/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docbuilder.py", line 602, in _get_docs_from_submodules subpackage_dir, docs[-1], options, progress_estimator) File "/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docbuilder.py", line 600, in _get_docs_from_submodules subpackage_file, options, progress_estimator, pkg_docs)) File "/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docbuilder.py", line 549, in _get_docs_from_module_file filename=filename, context=parent_docs[1]) File "/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docparser.py", line 278, in parse_docs process_file(module_doc) File "/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docparser.py", line 631, in process_file lineno, comments, decorators, encoding) File "/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docparser.py", line 756, in process_line return process_classdef(*args) File "/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docparser.py", line 1549, in process_classdef class_doc.bases.append(find_base(base_name, parent_docs)) File "/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docparser.py", line 1624, in find_base return parse_docs(name=str(base_var.imported_from)) File "/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docparser.py", line 219, in parse_docs val_doc = _find(name) File "/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docparser.py", line 393, in _find return _find(name[1:], module_doc) File "/home/kveroneau/django15-env/lib/python2.6/site-packages/epydoc/docparser.py"
Re: Epydoc failed to generate documentation for Django 1.5
Take a look at the generic views auto-generated docs from Epydoc(link in my post), it's definitely breathtaking. Especially seeing how all the classes come together in a nice UML graph. It really provides some prospective on how hard the core Django developer work and think over a process like CRUD and how to make it extendable. it uses docstrings, which provide additional info on the classes and methods themselves. On Wednesday, 3 April 2013 22:26:06 UTC-5, Jacob Kaplan-Moss wrote: > > On Wed, Apr 3, 2013 at 10:19 PM, Kevin Veroneau > > > wrote: > > Is this Epydoc error related to Epydoc or something that Django > shouldn't > > have done in it's source code? > > It looks perhaps like something you'd need to fix -- the message about > settings.configure() indicates that you're loading code that requires > settings, but you haven't configured them -- but it's really hard to > say. > > Ultimately though I think if you want to do this it's probably going > to be on you; I'd be quite against making any changes to Django to > accommodate tools like Epydoc. I'm quite skeptical about the value > that auto-generated documentation provides, so I'm going to encourage > any effort spent on documentation to be spent writing prose, not > trying to trick a machine into writing prose. > > Jacob > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
docs.djangoproject.com very slow
Not sure where to report this, but the docs.djangoproject.com is going very slow today, and I received a "504 Gateway Time-out" from the nginx server. Any ideas? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
