"Save as new" should redirect to the created item instead of list view
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.
Add support for unsigned primary keys in MySQL
I've picked up this old ticket: https://code.djangoproject.com/ticket/56 After some initial discussions on #django-dev it seems like wontfixing it would be an option too, so I wanted to ask about core devs' view on this: Is implementing opt-in support for unsigned primary keys on MySQL still interesting? -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAOXH8SX2gdM3OSDYkY7W94MVac%2Bh9Wo68r2qaRzisbEiYOzhoA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Provide free, simple, small-scale hosting for new users
Would it make sense to have at least something about live deployment at the end of the tutorial? Among other things, it could mention https://code.djangoproject.com/wiki/DjangoFriendlyWebHosts and/or http://djangofriendly.com/ On Thu, Jun 4, 2015 at 11:25 PM, Marc Tamlyn <marc.tam...@gmail.com> wrote: > Heroku also offers free hosting of a sort. The DSF has nowhere near the > financial muscle or human resources to provide such a service. There could > be an argument to document possible free hosting platforms, but the django > project generally avoids advertising any particular company (or third party > package for that matter). > > On 4 June 2015 at 16:23, Tim Graham <timogra...@gmail.com> wrote: > >> PythonAnyware provides free hosting and that's what the Django Girls >> tutorial uses: http://tutorial.djangogirls.org/en/deploy/README.html >> >> I don't think the Django Software Foundation needs to build a service >> like that. >> >> >> On Thursday, June 4, 2015 at 11:08:01 AM UTC-4, Markus Amalthea Magnuson >> wrote: >>> >>> Had discussions on an idea during DjangoCon Europe that I thought I'd >>> just throw out there on this list as well: >>> >>> What if the Django project provided free hosting for small projects, so >>> that any newcomer who went through the tutorial or similar could actually >>> deploy their application somewhere in as few steps as possible, a >>> mini-Heroku of sorts. I think it could be of immense value for someone who >>> built their first thing to show it to their friends without having to delve >>> deep into devops. This could be coupled with easy instructions on how to >>> move that application to proper hosting such as Heroku or AWS. >>> >>> There are so many aspects of this that would have to be solved (how to >>> limit, auth, etc.), so this is just testing the idea. What do you think? >>> >> -- >> 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 http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/23d32e1c-d31f-4043-81b9-0338c0298cf8%40googlegroups.com >> <https://groups.google.com/d/msgid/django-developers/23d32e1c-d31f-4043-81b9-0338c0298cf8%40googlegroups.com?utm_medium=email_source=footer> >> . >> >> 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 http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAMwjO1HKMY6NohAjwhrg0tm%2BQErp5Yd7eCtTKbwugJkuZnM-Kw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAMwjO1HKMY6NohAjwhrg0tm%2BQErp5Yd7eCtTKbwugJkuZnM-Kw%40mail.gmail.com?utm_medium=email_source=footer> > . > > 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAOXH8SVBPzkr3O-8EOCuFbx1OD5RgH_JaD7d6ALc91GGEko7iQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
More components in Trac for non-technical aspects
Another idea spawned during DjangoCon Europe: Would it make sense to have more non-technical components in Trac? I'm thinking of e.g. "Inclusion" that tracks how the project presents itself to new users, "Diversity" for tracking improvements to various such aspects, etc. etc. These are just a couple of examples, there's surely more along the same lines, and better ones than mine. Thoughts? -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/638d7358-38a6-48e4-a5fa-062270664e7f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Provide free, simple, small-scale hosting for new users
Had discussions on an idea during DjangoCon Europe that I thought I'd just throw out there on this list as well: What if the Django project provided free hosting for small projects, so that any newcomer who went through the tutorial or similar could actually deploy their application somewhere in as few steps as possible, a mini-Heroku of sorts. I think it could be of immense value for someone who built their first thing to show it to their friends without having to delve deep into devops. This could be coupled with easy instructions on how to move that application to proper hosting such as Heroku or AWS. There are so many aspects of this that would have to be solved (how to limit, auth, etc.), so this is just testing the idea. What do you think? -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5c3a1e3a-65c5-431f-9cc5-f4c3215a3caf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Feature proposal: Conditional block tags
I see both of your points, but I should also mention that a better example
than what I provided is when you want to have a block inside an
if-statement, which is not possible today:
{% if myvariable %}
{% block myblock %}my content{% endblock %}
{% endif %}
That inner block will always be rendered. A conditional version would look
like:
{% block myblock if myvariable %}my content{% endblock %}
Anyway, if there is still consensus that this is not a desirable feature,
feel free to close the ticket at:
https://code.djangoproject.com/ticket/24232
On Sat, Jan 31, 2015 at 2:17 PM, Marc Tamlyn <marc.tam...@gmail.com> wrote:
> I personally don't see any problem with the existing syntax and find it
> much easier to understand.
>
> On 31 January 2015 at 12:43, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> Hello,
>>
>> That’s a rather specialized behavior for the general purpose {% block %}
>> tag.
>>
>> I’m not convinced that building in such specialized behavior beats
>> composing blocks i.e. handling the condition with a {% if %} tag.
>>
>> The Django template language has way too much ad-hoc, inconsistent syntax
>> in its built-in tags. I don’t like the idea of adding more.
>>
>> We have to balance saving keystrokes against increasing the amount of
>> things every Django user needs to know. In this regard, adding that new
>> syntax looks like a bad tradeoff to me.
>>
>> --
>> Aymeric.
>>
>>
>>
>> On 30 janv. 2015, at 19:46, Markus Amalthea Magnuson <
>> markus.magnu...@gmail.com> wrote:
>>
>> Hey all,
>>
>> Tim Graham suggested I posted to this list regarding an idea for a new
>> feature: conditional block tags.
>>
>> I've summarized the feature in this ticket:
>> https://code.djangoproject.com/ticket/24232
>>
>> The basic idea is to be able to write something like this in a template:
>>
>> {% block myblock if myvariable %}my content{% endblock %}
>>
>> If the condition is false it is as if the block wasn't there, meaning its
>> parent would be rendered instead, if it exists.
>>
>> This is really a short form of:
>>
>> {% if myvariable %}
>> my content
>> {% else %}
>> {{ block.super }}
>> {% endif %}
>>
>> Note that it may seem similar to ticket #9173 but they are different,
>> which I try to make clear in this comment:
>> https://code.djangoproject.com/ticket/24232#comment:2
>>
>> So, what do you think?
>>
>> --
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/9ce259ff-6a2e-493a-a6df-1c15b43fe9c0%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/9ce259ff-6a2e-493a-a6df-1c15b43fe9c0%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/E5734A77-AE8F-4F70-BA87-97F2D77D5488%40polytechnique.org
>> <https://groups.google.com/d/msgid/django-developers/E5734A77-AE8F-4F70-BA87-97F2D77D5488%40polytechnique.org?utm_medium=email_source=footer>
>> .
>>
>> 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 http://groups.google.com/group/django-d
Feature proposal: Conditional block tags
Hey all,
Tim Graham suggested I posted to this list regarding an idea for a new
feature: conditional block tags.
I've summarized the feature in this
ticket: https://code.djangoproject.com/ticket/24232
The basic idea is to be able to write something like this in a template:
{% block myblock if myvariable %}my content{% endblock %}
If the condition is false it is as if the block wasn't there, meaning its
parent would be rendered instead, if it exists.
This is really a short form of:
{% if myvariable %}
my content
{% else %}
{{ block.super }}
{% endif %}
Note that it may seem similar to ticket #9173 but they are different, which
I try to make clear in this
comment: https://code.djangoproject.com/ticket/24232#comment:2
So, what do you think?
--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/9ce259ff-6a2e-493a-a6df-1c15b43fe9c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
