Feedback on improving GeoDjango docs

[Sylvain Fankhauser]

Hello,

I'm currently working on ticket #22274
, which is an effort to
improve the GeoDjango documentation to make it more accessible to
newcomers. This represents quite some work and I'm still in the early
stages but I'd love to have some feedback on the general structure I'm
planning to create. You can find the current status of the potential new
docs here: http://sephii.github.io/django-22274/ref/contrib/gis/index.html
(current version of the docs can be found here
https://docs.djangoproject.com/en/1.9/ref/contrib/gis/).

The tutorial part is not yet representative of what I'm planning to do so
no need to check that yet. That said, I found it quite difficult to come up
with a tutorial topic that would allow me to get through most of the
features from GeoDjango. So if you have an idea for a usecase I could use
for the tutorial, this would be more than welcome.

Some other things I have on my todo list are:

* Clarify installation instructions, split the platform-specific
instructions into separate documents
* Check if we can try to merge together some parts in the "Models" section
(ie. GeoDjango Database API, Geographic Database Functions and GeoQuerySet
API Reference), which all serve the same purpose

If you see anything else, feel free to comment.

Cheers,
Sylvain

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAAXOc44Kp8JVpEZ9zgUAw-aFdT30MdtjodAb7R4SzY2PB7LYsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

"Save as new" should redirect to the created item instead of list view

[Markus Amalthea Magnuson]

Currently, using the "Save as new" button will redirect to the list view,
while it would be more useful for it to redirect to the newly created item.
This also makes it much easier to create a series of new objects where the
next one only differs slightly from the last one.

There is a ticket for this here: https://code.djangoproject.com/ticket/16327

My proposal, based on the suggestions in that ticket, is that we change the
default behavior and redirect to the new item instead. Also, we add the
option ModelAdmin.save_as_continue (with default value True) so that anyone
can revert to the old behavior by setting it to False.

How does that sound?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAOXH8SXUnCh4y%3DO5vX2m%3D8YSm5ZHUw1fh_XZaDhfAbJ_PFbrxg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

utils.suppress_warning, TestCase.assertWarns

[Shai Berger]

Hi all,

While working on a ticket that had to do with cookies, I found myself writing 
this code (essentially):

with warnings.catch_warnings(record=True) as warnings_log:
#
# Begin actual code I'm trying to test
#
CsrfViewMiddleware().process_view(req, token_view, (), {})
#
# End actual code I'm trying to test
#
if (len(warnings_log) > 1 or 
not issubclass(warnings_log[0].category, UnicodeWarning)):
for warning in warnings_log:
warnings.warn(warning)

The code I'm trying to test is going to make a UnicodeWarning, because the 
whole point of the test is to see how the code deals with broken user input. 
Having to wrap it in 5 lines of unrelated code feels odd.

So I thought a context manager to suppress specific warnings in a block might 
be generally useful, and for tests, it may be even useful to have an 
assertWarns -- an analog of assertRaises.

Opinions?

Thanks,
Shai.

Re: A helpful ImportError for manage.py when Django isn't installed/available

[Collin Anderson]

We could also wait til after we remove py2 support in January. That way we
can be sure that on py3 it will also print the original exception so it
doesn't get hidden. (Right?)

On Fri, Apr 1, 2016 at 6:23 AM, Shai Berger  wrote:

> An idea: Catch the exception; in the handler, try to simply "import
> django".
> If this works, reraise, if it fails, print helpful message.
>
> On Thursday 31 March 2016 20:15:05 Tim Graham wrote:
> > Ben Welsh (palewire) raised a proposal on a GitHub pull request [0]:
> >
> > I've seen newbies flounder when they receive this error after running
> > manage.py.
> >
> > $ python manage.py
> > Traceback (most recent call last):
> >   File "manage.py", line 7, in 
> > from django.core.management import execute_from_command_line
> > ImportError: No module named django.core.management
> >
> > The root cause is almost always simple, like forgetting install Django
> with
> > pip or neglecting to "activate" a virtual environment. But the Python
> > jargon doesn't do much to help people new to our world connect the dots.
> >
> > My proposal: Catch that error and print out a more verbose message that
> > explains to the user exactly what's wrong. Here's my draft. I'd welcome
> any
> > changes, but I think something along these lines could better welcome new
> > people into Django.
> >
> > Traceback (most recent call last):
> >   File "manage.py", line 11, in 
> > installed and available on your PATH variable?")
> > ImportError: Couldn't import Django. Are you sure it's installed and
> > available on your PYTHONPATH environment variable? Did you forget to
> > activate a virtual environment?
> >
> >
> >
> > -
> > Claude says, "I'm not convinced about this. Aren't we hiding other
> possibly
> > helpful import errors (at least on Python 2)?"
> > Aymeric says, "I share Claude's concern. We've been constantly removing
> > that sort of "helpful" exception wrapping from Django"
> > Aymeric again, after further investigation, "Importing
> > django.core.management doesn't ripple too far. Specifically it doesn't
> > import any of the user's code. This reduces the likelihood of masking
> > useful errors. It will mask exception info if Django is installed
> > incorrectly, for instance because two installs happened in the same
> > location (but I think that's less likely since pip/virtualenv became
> > mainstream and since we added code to setup.py to detect existing
> > installs).
> >
> > Does anyone else have opinions on the change? I suppose another option
> > could be to try to reraise the original exception with the "helpful
> > message" added.
> >
> >
> > [0] https://github.com/django/django/pull/6314
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S7xXEUzRXRS%2BPDHc0%2Bso_aa0jkNSO9M0wTD%3DcFXrxHb0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

New `pre_handler()` method on Class-Based Views

[Pablo Recio]

Hey there,

Wanted to share an idea I had during some discussions in DjangoCon EU. When 
using CBV, sometimes we have to replicate behaviour between different 
handlers. For instance setting up certain objects, extra user checks... 
Normally the way to achieve this is to override the `dispatch()`, but it's 
a bit error-prone and doesn't feel too clean sometimes.

So I wrote a little piece of code that adds a `pre_handler()` method that 
gets called before the handler method, whatever that is. Here is the 
code: https://github.com/pablorecio/django/tree/pre-handler-view-method, if 
it's something that would get merged I'll happily submit a PR.

Thanks!
Pablo Recio


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/df0c7703-b496-4bfa-ad31-68b35be482fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New `pre_handler()` method on Class-Based Views

[Ryan Hiebert]

I have taken to using a prepare method called from dispatch which takes the 
request  args, and I use it primarily to resolve ids in the url to db objects. 
This sounds like it fills a similar purpose.

Sent from my iPhone

> On Apr 3, 2016, at 14:07, Pablo Recio  wrote:
> 
> Hey there,
> 
> Wanted to share an idea I had during some discussions in DjangoCon EU. When 
> using CBV, sometimes we have to replicate behaviour between different 
> handlers. For instance setting up certain objects, extra user checks... 
> Normally the way to achieve this is to override the `dispatch()`, but it's a 
> bit error-prone and doesn't feel too clean sometimes.
> 
> So I wrote a little piece of code that adds a `pre_handler()` method that 
> gets called before the handler method, whatever that is. Here is the code: 
> https://github.com/pablorecio/django/tree/pre-handler-view-method, if it's 
> something that would get merged I'll happily submit a PR.
> 
> Thanks!
> Pablo Recio
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/df0c7703-b496-4bfa-ad31-68b35be482fa%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/AFBC3432-F9C6-40CA-9A4E-A194AA84C5C7%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.