I've always felt that `is_staff` should be changed to a permission such as
`can_access_admin` provided by the Admin app itself. However,
`is_superuser` is slightly different, in that it's not a permission, but
rather a flag that says "this user has EVERY permission". It's also
potentially nonsensic
In previous projects (before moving to rolling my own UI components), I
ended up favouring Selectize (http://selectize.github.io/selectize.js/)
after getting fed up with Chosen and Select2 - but this was a few years ago
and I can't remember my reasons. But if it hasn't been considered, it might
be
rything that's annoyed me
about web dev for the last 10 years. But Django has an excellent data
layer, and I want to keep using it if I can.
Andy
On 2 June 2015 at 18:17, Emil Stenström wrote:
> On Tuesday, 2 June 2015 12:58:22 UTC+2, Andrew Ingram wrote:
>>
>> Based on my o
Based on my own experiences building isomorphic JavaScript apps with
Django, I haven't had any issues where I felt Django was getting in my way.
I've tackled the problem in two different ways, both of which worked
without any great difficulty:
1. The primary web-app is actually a node process. Eve
For what it's worth, I prefer one import per line, if only because it makes
diffs that involve changes to imports a lot easier to digest, and usually
smaller.
ie, something like this:
https://gist.github.com/AndrewIngram/16da35699bd495f79adb
Andy
On 30 January 2015 at 09:36, aRkadeFR wrote:
ke a database column as far as the model is concerned, but isn't
one in reality.
Regards,
Andrew Ingram
On 22 December 2014 at 14:50, Collin Anderson wrote:
> Ditto. I'm ok with a tiny shim for GFK, and we should get the API right
> for RelatedObject going forward, (as long as
Having basically built all of the views in question, I agree with Russell.
By having multiple form classes in a view itself, you're essentially
pulling validation logic out of the form and into the view where it doesn't
belong. A view shouldn't be concerned with the specifics of validation, it
shou
ugust 23, 2013 6:25:42 PM UTC+3, Andrew Ingram wrote:
>>
>> I'd love to see this solved. I'm not sold on the API, but then again I've
>> yet to see a single suggested API for this problem that I actually like.
>>
>> I showed you this a little while ago, you h
I'd love to see this solved. I'm not sold on the API, but then again I've
yet to see a single suggested API for this problem that I actually like.
I showed you this a little while ago, you had some reservations with my
idea, but I figured I might as well add it to the conversation anyway:
https://
On 12 May 2013, at 00:55, Russell Keith-Magee wrote:
> I'm sure I understand this argument. Python objects are passed around by
> reference, not by value, so if you've passed in a Django object deep into
> another library, that library will be pointing at the same instance. If the
> instance is
On 1 May 2013, at 00:35, Carl Meyer wrote:
> On 04/30/2013 05:27 PM, Andrew Ingram wrote:
>> Absolutely, there's no requirement to migrate, but it does have the
>> feel of an weird kind of deprecation. Obviously there are
>> workarounds, like you said, I can upgra
On 1 May 2013, at 00:13, Donald Stufft wrote:
>
> On Apr 30, 2013, at 7:10 PM, Andrew Ingram wrote:
>
>> On 30 Apr 2013, at 23:38, Shai Berger wrote:
>>> I see one issue with this: According to current procedures, if this
>>> timeline
>>> is foll
On 30 Apr 2013, at 23:38, Shai Berger wrote:
> I see one issue with this: According to current procedures, if this timeline
> is followed, support for 1.4 will be dropped less than 6 months after the
> release of 1.5. At least for some of us (which, as I mentioned earlier on the
> list, only mo
The original use case for pk_url_kwarg and slug_url_kwargs was something
like this:
/(?P[\w-]*)/ - DetailView
/(?P[\w-]*)/another-resource/ - Scoped ListView
/(?P[\w-]*)/another-resource/(?P[\w-]*) - Scoped
DetailView
In this case, the Scoped ListView and Scoped DetailView would both inherit
a mi
I've been wanting this exact feature for years. I've always struggled to
explain the problem, but I've had numerous cases where this would have made
for a vastly simpler template structure.
Big +1 from me.
On 17 April 2013 16:50, Emil Stenström wrote:
> Hi,
>
> Proposal:
> Make it possible to
On 10 April 2013 14:56, Javier Guerra Giraldez wrote:
> check django-storages
> http://django-storages.readthedocs.org/en/latest/ it includes several
> storage backends, S3 among them.
>
> --
> Javier
I think he was asking whether the storage API should be extended to
support additional operatio
On 29 Mar 2013, at 17:22, Bernhard Ja wrote:
> Hello together,
> this is my first post to the Django developers list. Please let me know if
> this topic is better placed on Django users :-)
>
> For i18n there is a javascript_catalog view we can use to access translations
> in javascript.
> Acc
The approach we take at work is to have a view that wraps around the
product, category and occasion views and takes care of the fallthrough
logic. I'm not a fan of this approach, because it means that you can't just
look at the urlconf and see which pattern maps to which view function. On
the other
problem in test.
>
> Can you post some code to help us reproduce it?
>
> Thanks,
> Mike
>
>
> On Tuesday, October 23, 2012 3:52:10 AM UTC-7, Andrew Ingram wrote:
> Hi all,
>
> This one stung me today. Basically as part of an event (calendar) app, I have
> fun
ugh this is the first time I've ever come across such a
problem so it might be a one-off.
Regards,
Andrew Ingram
--
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.
On 25 September 2012 17:45, Alex Ogier wrote:
> There's a big thing you cannot do without grouping models: you can't have
> an abstract base class relate to another abstract base class. Django's
> foreign key mechanism doesn't know how to relate to a to-be-instantiated
> concrete class.
>
Not en
I can see a use case for this, but would this not work?
from django.db.models import get_model
post_save.connect(
my_signal_handler,
sender=get_model('my_app', 'MyModel'),
)
As long as the app cache has been initialised before you call get_model,
this should work fine.
- Andy
On 22
On 7 June 2012 18:17, Andrew Godwin wrote:
> This means either having to register custom fields (like admin classes,
> for example), or requiring fields to live in a fields.py or fields
> package (like models and models.py). This is to provide for a
> less-fragile way of referring to them than the
o like to see it possible at model
definition time, either using a decorator (like above) or a Meta
option like 'replaces'. The risk, of course, is that it means any
third-party app could override any other model without you necessarily
being aware of it, not sure how this would be mitigat
Hi Iván,
I'd temporarily given up on getting extra_views into Django because of
a blocking issue with pagination and formsets.
Assuming a goal is to be able to build a new admin using class-based
views, there is a prerequisite of being able to paginate, sort and
filter on the querysets used for m
It seems to me there'd be more mileage in making new class-based
versions of the auth views.
- Andy
On 24 May 2012 13:51, Florian Apolloner wrote:
> Hi,
>
> -1 from me here.
>
> A) why don't you have site_name_name etc (those are still fixed).
> B) templates need to be able to rely on a name, if
adds this facility to BaseFormSet, I
think the formset factories will need to hook into it as well.
Regards,
Andrew Ingram
On 24 April 2012 14:55, Tom Evans wrote:
> Hi all
>
> I raised a ticket about this new feature, with patch:
>
> https://code.djangoproject.com/ticket/18166
>
to delay the evaluation
until after the urlconf has been initialised.
I don't think there's a real benefit to having a third approach.
Regards,
Andrew Ingram
On 8 Apr 2012, at 22:12, Martin Tiršel wrote:
> Hello,
>
> I just started to use class based views and I came to
On 16 February 2012 15:42, Łukasz Rekucki wrote:
> 1) I can't argue about popularity, because I have no data, but most
> Django applications I use come from github, so it's also quite
> popular.
>
> 2) I don't think Django should care if the collaboration tool runs
> python/django or java/grails a
case would be. SingleObjectMixin is
designed to only ever give you one object back (though I'm surprised it doesn't
handle the MultipleObjectsReturned exception), so out of all the lookup choices
we have, only an exact match on a unique field makes sense. Am I missing
something he
On 10 October 2011 13:13, Russell Keith-Magee wrote:
>
> The approach taken by django-messages should be the model here. When a
> new messages framework was proposed for Django in 1.2, an effort was
> made to find out all the features that were desirable, and then pull
> together all those features
On 9 Jul 2011, at 10:44, Sam Lai wrote:
> I concur. The consensus seems to be shifting towards a 'strip' flag
> though (defaulting to false), and I'm +1 on that. That would make it
> explicit, minimise repetitive boilerplate code and also make it less
> likely to accidentally forget to strip a fie
Hi Julien,
I'm already involved on that ticket, the pagination issue is part of what's
holding me back from contributing a patch. So I was looking to get some
discussion about whether it's something that needs to be solved in core. In
light of what you've said, I'm trying to think of a more str
take
advantage of it for free.
This is only one use case, but I'm sure there are more. I'm happy to
try and come up with a patch if there's some agreement on this.
The FormSet views I've developed can be seen here:
https://github.com/AndrewIngram/django-extra-views/blob/maste
rks gradually move towards best practices it'll become increasingly
difficult to tell them apart. This is definitely a good thing, I am generally
rather pleased if I can deploy something without someone knowing what server
side tools are in use.
- Andrew Ingram
--
You received this me
35 matches
Mail list logo