Re: Django Admin Revamp - Any updates?
Thank you! I discovered a video on the wild showcasing the installing and usage of django-admin-bootstrapped. If anyone is curious to see it in motion, here's the link (already at the correct second): http://youtu.be/St-30zsoDus?t=1h11m35s On Friday, December 14, 2012 2:45:41 AM UTC+1, Victor Hooi wrote: > > Hi, > > Wow, that does look nice =). > > I know it's just a re-skin, but I do like the look. > > It'll be curious to see whether the Django Core team would look at using > this, and/or whether they're doing a deeper overhaul of the Admin > interface... > > Cheers, > Victor > > On Friday, 14 December 2012 07:31:45 UTC+11, Riccardo Forina wrote: >> >> Hi all, >> >> I have an alpha version of a restyling of the django admin done with >> Bootstrap here: >> https://github.com/riccardo-forina/django-admin-bootstrapped >> Based on my personal experience - I'm using it on several production >> sites - it's working pretty well. >> >> Maybe it can be a starting point for the UI revamp everybody is >> expecting. What do you think? >> >> Riccardo >> >> >> On Friday, November 23, 2012 11:05:57 PM UTC+1, Victor Hooi wrote: >>> >>> Hi, >>> >>> Aha, I didn't realise he live in Tel Aviv. Perhaps I should FB stalk >>> people more *grins*. >>> >>> Well, our prayers are with you, Idan, hope you're keeping safe =). >>> >>> Cheers, >>> Victor >>> >>> >>> On Thu, Nov 22, 2012 at 1:01 PM, Jeremy Dunck wrote: >>> For the record: It's bad timing for Idan. He lives in Tel Aviv which is currently receiving intermittent rocket attacks. He may be a bit slow to respond. ;) Let's wish him and his family safety and the luxury of worrying about django's admin in good time. On Thu, Nov 15, 2012 at 7:23 AM, Victor Hooi wrote: > Hi, > > I'm guessing there aren't any updates on this? Lol. > > Idan - you mentioned you'd like to get thoughts on what we hope to achieve > in a new admin - basically, what is the purpose of Django's contrib.admin - > is that right? > > Is there some place that people can brainstorm or contribute their thoughts > on this? Should somebody make a wiki page for collecting all this? > > Cheers, > Victor > > > On Friday, 18 May 2012 20:18:59 UTC+10, patrickk wrote: >> >> I agree with Idan. We mainly did Grappelli because of the look & feel (and >> then added some functionality like autocompletes). >> >> However, it just doesn´t make sense to simply "beautify" the existing >> admin-interface. Rethinking the functionality, adding flexibility, being >> able to customize ... these are all necessary steps IMHO, but I´m still >> missing a clear approach/roadmap on how/when this should happen. >> >> I planned to give a talk on djangocon.eu about how to improve the >> admin-interface. Unfortunately, I had to step back from that idea because of >> some customer-related projects. Still, the thoughts are there and I´m happy >> to discuss this issue anytime. This discussion could start with defining the >> so-called "trusted editor" – what does he/she knows resp. needs to know when >> dealing with the admin-interface? What are the consequences (e.g., does an >> editor care about an app-list, does he even know what it is)? What >> working-groups do we need (python, html/css, js, ...)? How can we publish >> the process/discussion? And much more ... let´s start ... but how? >> >> best, >> patrick >> >> >> Am Montag, 30. April 2012 23:41:14 UTC+2 schrieb Idan Gazit: >>> >>> >>> >>> On Monday, April 30, 2012 at 10:16 AM, Brett H wrote: >>> >>> > Increasing the flexibility for development and integration is more >>> > important than trying to 2nd guess where we are going to be in 5 years >>> > time. >>> >>> Fair enough, but that sort of flexibility is available now. Nothing is >>> preventing you from starting your 3rd-party admin app today. >>> >>> >>> >>> The issue is Django's officially-blessed, officially-documented admin. >>> I'm not sure it's better to have admin in contrib (or contrib at all, but >>> that's a separate ball of wax). I have a feeling that this issue will >>> probably be addressed once again now that we're on github. >>> >>> All the same, if there's going to be an official django admin, I'd like >>> it to give some thought to the issues I've raised. I have no problem (read: >>> would love) to draw upon existing solutions for an admin revamp, but right >>> now I don't have a fitness function to guide my decisions, and I think that >>> is necessary. Not a spec, just an attempt to step back and think about what >>
Re: Django Admin Revamp - Any updates?
Hi, Wow, that does look nice =). I know it's just a re-skin, but I do like the look. It'll be curious to see whether the Django Core team would look at using this, and/or whether they're doing a deeper overhaul of the Admin interface... Cheers, Victor On Friday, 14 December 2012 07:31:45 UTC+11, Riccardo Forina wrote: > > Hi all, > > I have an alpha version of a restyling of the django admin done with > Bootstrap here: > https://github.com/riccardo-forina/django-admin-bootstrapped > Based on my personal experience - I'm using it on several production sites > - it's working pretty well. > > Maybe it can be a starting point for the UI revamp everybody is expecting. > What do you think? > > Riccardo > > > On Friday, November 23, 2012 11:05:57 PM UTC+1, Victor Hooi wrote: >> >> Hi, >> >> Aha, I didn't realise he live in Tel Aviv. Perhaps I should FB stalk >> people more *grins*. >> >> Well, our prayers are with you, Idan, hope you're keeping safe =). >> >> Cheers, >> Victor >> >> >> On Thu, Nov 22, 2012 at 1:01 PM, Jeremy Dunck wrote: >> >>> For the record: It's bad timing for Idan. He lives in Tel Aviv which >>> is currently receiving intermittent rocket attacks. He may be a bit >>> slow to respond. ;) >>> >>> Let's wish him and his family safety and the luxury of worrying about >>> django's admin in good time. >>> >>> On Thu, Nov 15, 2012 at 7:23 AM, Victor Hooi wrote: >>> > Hi, >>> > >>> > I'm guessing there aren't any updates on this? Lol. >>> > >>> > Idan - you mentioned you'd like to get thoughts on what we hope to >>> achieve >>> > in a new admin - basically, what is the purpose of Django's >>> contrib.admin - >>> > is that right? >>> > >>> > Is there some place that people can brainstorm or contribute their >>> thoughts >>> > on this? Should somebody make a wiki page for collecting all this? >>> > >>> > Cheers, >>> > Victor >>> > >>> > >>> > On Friday, 18 May 2012 20:18:59 UTC+10, patrickk wrote: >>> >> >>> >> I agree with Idan. We mainly did Grappelli because of the look & feel >>> (and >>> >> then added some functionality like autocompletes). >>> >> >>> >> However, it just doesn´t make sense to simply "beautify" the existing >>> >> admin-interface. Rethinking the functionality, adding flexibility, >>> being >>> >> able to customize ... these are all necessary steps IMHO, but I´m >>> still >>> >> missing a clear approach/roadmap on how/when this should happen. >>> >> >>> >> I planned to give a talk on djangocon.eu about how to improve the >>> >> admin-interface. Unfortunately, I had to step back from that idea >>> because of >>> >> some customer-related projects. Still, the thoughts are there and I´m >>> happy >>> >> to discuss this issue anytime. This discussion could start with >>> defining the >>> >> so-called "trusted editor" – what does he/she knows resp. needs to >>> know when >>> >> dealing with the admin-interface? What are the consequences (e.g., >>> does an >>> >> editor care about an app-list, does he even know what it is)? What >>> >> working-groups do we need (python, html/css, js, ...)? How can we >>> publish >>> >> the process/discussion? And much more ... let´s start ... but how? >>> >> >>> >> best, >>> >> patrick >>> >> >>> >> >>> >> Am Montag, 30. April 2012 23:41:14 UTC+2 schrieb Idan Gazit: >>> >>> >>> >>> >>> >>> >>> >>> On Monday, April 30, 2012 at 10:16 AM, Brett H wrote: >>> >>> >>> >>> > Increasing the flexibility for development and integration is more >>> >>> > important than trying to 2nd guess where we are going to be in 5 >>> years >>> >>> > time. >>> >>> >>> >>> Fair enough, but that sort of flexibility is available now. Nothing >>> is >>> >>> preventing you from starting your 3rd-party admin app today. >>> >>> >>> >>> >>> >>> >>> >>> The issue is Django's officially-blessed, officially-documented >>> admin. >>> >>> I'm not sure it's better to have admin in contrib (or contrib at >>> all, but >>> >>> that's a separate ball of wax). I have a feeling that this issue will >>> >>> probably be addressed once again now that we're on github. >>> >>> >>> >>> All the same, if there's going to be an official django admin, I'd >>> like >>> >>> it to give some thought to the issues I've raised. I have no problem >>> (read: >>> >>> would love) to draw upon existing solutions for an admin revamp, but >>> right >>> >>> now I don't have a fitness function to guide my decisions, and I >>> think that >>> >>> is necessary. Not a spec, just an attempt to step back and think >>> about what >>> >>> the admin should do. >>> >>> >>> >>> -I >>> >>> >>> >>> >>> > -- >>> > 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/-/CTFFiNcb9KMJ. >>> > >>> > To post to this group, send email to django-d...@googlegroups.com. >>> > To unsubscribe from this group, send email to >>> > django-develop...@googleg
Re: Django Admin Revamp - Any updates?
Hi all, I have an alpha version of a restyling of the django admin done with Bootstrap here: https://github.com/riccardo-forina/django-admin-bootstrapped Based on my personal experience - I'm using it on several production sites - it's working pretty well. Maybe it can be a starting point for the UI revamp everybody is expecting. What do you think? Riccardo On Friday, November 23, 2012 11:05:57 PM UTC+1, Victor Hooi wrote: > > Hi, > > Aha, I didn't realise he live in Tel Aviv. Perhaps I should FB stalk > people more *grins*. > > Well, our prayers are with you, Idan, hope you're keeping safe =). > > Cheers, > Victor > > > On Thu, Nov 22, 2012 at 1:01 PM, Jeremy Dunck > > wrote: > >> For the record: It's bad timing for Idan. He lives in Tel Aviv which >> is currently receiving intermittent rocket attacks. He may be a bit >> slow to respond. ;) >> >> Let's wish him and his family safety and the luxury of worrying about >> django's admin in good time. >> >> On Thu, Nov 15, 2012 at 7:23 AM, Victor Hooi >> > >> wrote: >> > Hi, >> > >> > I'm guessing there aren't any updates on this? Lol. >> > >> > Idan - you mentioned you'd like to get thoughts on what we hope to >> achieve >> > in a new admin - basically, what is the purpose of Django's >> contrib.admin - >> > is that right? >> > >> > Is there some place that people can brainstorm or contribute their >> thoughts >> > on this? Should somebody make a wiki page for collecting all this? >> > >> > Cheers, >> > Victor >> > >> > >> > On Friday, 18 May 2012 20:18:59 UTC+10, patrickk wrote: >> >> >> >> I agree with Idan. We mainly did Grappelli because of the look & feel >> (and >> >> then added some functionality like autocompletes). >> >> >> >> However, it just doesn´t make sense to simply "beautify" the existing >> >> admin-interface. Rethinking the functionality, adding flexibility, >> being >> >> able to customize ... these are all necessary steps IMHO, but I´m still >> >> missing a clear approach/roadmap on how/when this should happen. >> >> >> >> I planned to give a talk on djangocon.eu about how to improve the >> >> admin-interface. Unfortunately, I had to step back from that idea >> because of >> >> some customer-related projects. Still, the thoughts are there and I´m >> happy >> >> to discuss this issue anytime. This discussion could start with >> defining the >> >> so-called "trusted editor" – what does he/she knows resp. needs to >> know when >> >> dealing with the admin-interface? What are the consequences (e.g., >> does an >> >> editor care about an app-list, does he even know what it is)? What >> >> working-groups do we need (python, html/css, js, ...)? How can we >> publish >> >> the process/discussion? And much more ... let´s start ... but how? >> >> >> >> best, >> >> patrick >> >> >> >> >> >> Am Montag, 30. April 2012 23:41:14 UTC+2 schrieb Idan Gazit: >> >>> >> >>> >> >>> >> >>> On Monday, April 30, 2012 at 10:16 AM, Brett H wrote: >> >>> >> >>> > Increasing the flexibility for development and integration is more >> >>> > important than trying to 2nd guess where we are going to be in 5 >> years >> >>> > time. >> >>> >> >>> Fair enough, but that sort of flexibility is available now. Nothing is >> >>> preventing you from starting your 3rd-party admin app today. >> >>> >> >>> >> >>> >> >>> The issue is Django's officially-blessed, officially-documented admin. >> >>> I'm not sure it's better to have admin in contrib (or contrib at all, >> but >> >>> that's a separate ball of wax). I have a feeling that this issue will >> >>> probably be addressed once again now that we're on github. >> >>> >> >>> All the same, if there's going to be an official django admin, I'd >> like >> >>> it to give some thought to the issues I've raised. I have no problem >> (read: >> >>> would love) to draw upon existing solutions for an admin revamp, but >> right >> >>> now I don't have a fitness function to guide my decisions, and I >> think that >> >>> is necessary. Not a spec, just an attempt to step back and think >> about what >> >>> the admin should do. >> >>> >> >>> -I >> >>> >> >>> >> > -- >> > 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/-/CTFFiNcb9KMJ. >> > >> > To post to this group, send email to >> > django-d...@googlegroups.com >> . >> > To unsubscribe from this group, send email to >> > django-develop...@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-d...@googlegroups.com >> . >> To unsubscribe from this group, send email to >> django-develop...@googlegroups.com . >> For more options, visit this group at >> http://groups.google
Re: Modify .save() implementation
I just thinking out loud here but: what if another thread does something to the previously loaded object? I'm not sure if Django has concurrency tests build into the test suite, but if it hasn't it could explain why the code is written as it is. On Friday, 30 November 2012 19:53:32 UTC+1, Anssi Kääriäinen wrote: > > I would like to change the implementation of .save(). In the following > case: > > s = SomeModel.objects.get(pk=somepk) > s.somefield = val > s.save() > > we currently do this: > > SELECT (from .get()) > SELECT (from .save()) > UPDATE > > The second SELECT is redundant. We have knowledge that the model was > loaded from the same DB in s._state. So, we could instead do just: > SELECT (from .get()) > UPDATE > > If the UPDATE doesn't match anything (due to concurrent delete for > example), then we can still do an INSERT. So, from user perspective > the behaviour isn't changed. > > The force_update flag isn't doing the exact same thing - when using > force_update and the UPDATE doesn't change anything the INSERT isn't > done, instead an error is risen. > > In most UPDATE situations this should reduce one SELECT from > model.save(). > > The only problem I can see is that we have very explicitly documented > how .save() behaves. The generated queries are documented. I don't > consider the generated queries part of the publlic API, just the > behaviour. > > All tests on all core backends do pass using the "UPDATE, if not > updated INSERT" behaviour. See ticket #16649 for patch & details. > > Any objections moving forward with this plan? > > - Anssi > -- 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/-/pDqtkw-B5v0J. 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: Django 1.1 is not installable
The exact versions of Django available on Pypi are here: http://pypi.python.org/simple/Django/ Nobody recommends installing this old version of Django for production, but you can install 1.1.4 like so: pip install django==1.1.4 On Wednesday, December 12, 2012 11:37:58 AM UTC-8, Will Van Wazer wrote: > > Despite not being listed on PyPi, installing Django 1.1 works if you do > this: > > pip install 'Django<1.2' > > > > --- > Will Van Wazer > The Washington Post > (202) 334-9967 (w) > (703) 785-1448 (c) > > > > On Wed, Dec 12, 2012 at 11:12 AM, Jacob Kaplan-Moss > > > wrote: > >> I'm not sure why it's hidden on PyPI, but in the meantime you can get it >> from https://www.djangoproject.com/download/. >> >> I should point out that 1.1 is woefully out of date and no longer >> receives security updates. There are probably security vulnerabilities and >> certainly bugs; you should really upgrade as soon as possible. >> >> Jacob >> >> >> On Wed, Dec 12, 2012 at 9:56 AM, Michael Elsdörfer >> >> > wrote: >> >>> $ pip install django==1.1 >>> Downloading/unpacking django==1.1 >>> Could not find a version that satisfies the requirement django==1.1 >>> (from versions: ) >>> No distributions matching the version for django==1.1 >>> >>> This was working perfectly well not so long ago. I notice 1.1 isn't >>> listed on PyPI either: >>> >>> http://pypi.python.org/pypi/Django >>> >>> Michael >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers" group. >>> To post to this group, send email to >>> django-d...@googlegroups.com >>> . >>> To unsubscribe from this group, send email to >>> django-develop...@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-d...@googlegroups.com >> . >> To unsubscribe from this group, send email to >> django-develop...@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 view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/LfYFbMDVPQ0J. 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: Proposal: Django URL Admin (django-urls)
For those of you following, development of django-urls has moved to github. Thanks https://github.com/django-urls/django-urls -- 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/-/PgzuqD1OMzcJ. 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: Single table inheritance - working implementation
On 11 joulu, 17:56, Anssi Kääriäinen wrote: > Would a model._meta.get_default_columns() work for you? While this > would still be internal API, it would be hopefully less likely to > change in ways that require extensive rewrites to 3rd party apps. First, the ._meta.get_default_columns() I proposed above doesn't actually make sense - the get_default_columns() does mostly things which belong to compiler, not to ._meta. Second, I have created a patch which should allow your work to continue working in master. See https://github.com/akaariai/django/commit/94c417d2a29a0f72b26019fc38ef400420097aa4 - the idea is to change get_fields_with_model() so that it doesn't return different values for proxy models compared to concrete models. I think this is a good solution overall, though this change is somewhat scary - get_fields_with_model is used in many places of the ORM... Third, I think it is a good idea to add more abstraction between the ORM and the Model/Fields layer. So, in this way I do support the idea of using proxy models for single table inheritance. On the other hand it should not be surprising if in the future "different fields than parents" proxy models will break again - it is almost the definition of proxy model that it has the same fields than its parent. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. 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.
