Re: Proposal: add static_fields to ModelAdmin
Now that 1.1 is out and proposals for 1.2 are being submitted I decided I would revive this proposal for comments --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: proper place to put startup code
On Thu, Sep 10, 2009 at 7:54 AM, Andrew Gwozdziewycz wrote: > > Sorry, I mistyped the email address; moving to django-users > > On Sep 10, 7:04 am, Andrew Gwozdziewycz wrote: >> Hello, >> >> What's the recommended place to put code that should be run once upon >> application initialization? I put such code in urls.py --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: NDjango - .Net port of Django template langauage
I dont know all that much about .Net but isnt the point of it that all the .Net languages can be used together? eg using C#.Net components in a VB.Net app and such. So why not just use the django template language as is via IronPython instead of trying to port it to another language? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Feature idea
There are currently several modules / apps that require auto discovery
based on whats listed in INSTALLED_APPS. admin, django_nav, and the
proposed startup.py and I know one or two other apps that use similar
methods but cannot remember their names off the top of my head.
I would like to propose a new setting AUTODISCOVER, an iterable of
module names to automatically load from each INSTALLED_APP after the
settings have been initialized. This would default to
AUTODISCOVER = (,)
_REQUIRED_AUTODISCOVER = ('startup',) #Assuming the startup.py
proposal is accepted
_REQUIRED_AUTODISCOVER is a separate setting in default_settings.py
that is combined with AUTODISCOVER during settings initialization
AUTODISCOVER = _REQUIRED_AUTODISCOVER + AUTODISCOVER
which will ensure the required auto discover modules are processed
first by the new autodiscover module
Currently each app / module that needs to be autodiscovered in some
way needs to re-implement something very similar to the admin
autodiscover @
http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/__init__.py
I think the new module should be @ django.core.autodiscover, look like
http://dpaste.com/hold/201868/ and be loaded immediately after
settings initialization.
Obviously for backwards compatibility the current django.contrib.admin
autodiscover needs to remain and function as it did, but should be
modified to look like http://dpaste.com/hold/201874/ to prevent the
admin from attempting to register itself twice if admin is already
being loaded by the new autodiscover method.
Dj Gilcrease
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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: Feature idea
On Tue, Jun 1, 2010 at 3:02 PM, Gregor Müllegger wrote: > My proposal would go into the direction of pulling the autodiscover > function out of the django.contrib.admin module and putting it > somewhere in the core. Since the admin needs some special > functionality on errors while loading an admin.py module from an app, > I would suggest a Autodiscover class that provides some hooks to be > better customizable. > > Something like: I like this idea better then mine provided the startup.py proposal goes forward. I very much dislike having autodiscover stuff being loaded in urls.py as a hack to get an app bootstrapped and part of what I am trying to solve is the need for app consumers (End Developers) to bootstrap your app in urls.py. I figured a setting was slightly more explicit then the bit of magic that would go on by having your own autodiscover sub-class being initiated in startup.py (I really think that should be named bootstrap.py but I digress). Even with the setting there is nothing preventing you from adding your module to the autodiscover setting when you call your management command, but as I said I like the class approach provided a application bootstrap system is provided. If the class based approach is chosen then I think it should love in django.utils.autodiscover as it is something the application developer must subclass if they want to use it, and if it is in core I would expect it to be something used internally and only to be tinkered with by advanced users. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Feature idea
On Wed, Jun 2, 2010 at 3:14 PM, Jacob Kaplan-Moss wrote: > Aat EuroDjangoCon Russ and I discussed a "startup" mechanism that'd > cover this use case, as well as a whole lot more. There's a few hints > in the logging discussion a few threads down. > > So I'm -1 on this specific proposal, but only because I expect it to > be obsoleted by me and Russ' startup proposal. Which one of us really > should write up :) Sounds good to me, my proposal was based on need and limited understanding of the startup proposal based on the mentioning of it in the logging thread where I assumed it would just be something like the admin's auto discovery that looked for startup.py instead of admin.py -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Build complex-navigation helper
On Thu, Jun 3, 2010 at 7:41 PM, M Rotch wrote: > The closest thing I've come across as a solution so far is > http://code.google.com/p/django-nav/ As the developer of django-nav it is nice to hear it is closest to a solution you have found, but often closest isnt enough, and I am not sure I understand what you are describing you need to do to get sub-sub-tabs working. Here is how I do it in the sites I maintain that go 3 levels deep for tabs base.html -> has main tabs /app/app_base.html -> extends base.html and has sub-tabs /app/view1.html -> extends app_base.html /app/view2.html -> extends app_base.html ... /app/sub_app_base.html -> extends app_base.html and has sub-sub-tabs /app/sub_view1.html -> extends sub_app_base.html /app/sub_view2.html -> extends sub_app_base.html ... -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Query Refactor Status Update
Wouldnt an autofield like http://dpaste.com/hold/205665/ work where connection.creation.auto_field_base_type is set to int by default in django/db/backends/creation.py but could be overridden by an individual backend to be str or unicode or whatever? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Ticket #2507
I would give the Devs a little more time as they are still deciding what will make it into 1.1 and what wont, as well as fixing bugs in the 1.0.x branch. I use this for two of my projects and would love to see it included in release, but it is not that hard to add on my own Dj Gilcrease OpenRPG Developer ~~http://www.openrpg.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Unique CharField greater than 256 characters on MySQL Fails - what is the correct solution
The max length of a varchar field is Database dependent MySQL it is 255 MSSQL it is 2^31-1 (2gb) PostgreSQL it is ~ 2^20-1 (1gb) MySQL 4.1 and greater supposedly changes any varchar or char field with a max length or greater to 255 to a TEXT field which can hold ~ 1gb Dj Gilcrease OpenRPG Developer ~~http://www.openrpg.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Proposal: AnonymousUser that you can set specific permissions for
The reason for this Proposal and patch is because I do not like having to special case permissions for the AnonymousUser for every model I wish to allow them access to. I am working on an ACL that has no concept of User per say, it is using a generic relationship to maintain a list of subjects and objects that it controls, so subject and object can be any Model. In the ACL you will primarily use it for Users and Groups as subject and other models as objects, but you could potentially restrict one Models access to another (why I dont know, other then using a diff user model then the builtin one, but you can). The fact that the AnonymousUser has no model makes it impossible for me to add them as a subject to my ACL, or for any other permissions system to manage them other then special casing. Special casing is all well and good when you are not doing Row level permissions, as there are not going to be that many special cases, but once you start getting into row level permissions there could potentially be hundreds (or thousands) of cases when I would need to do special casing just for the AnonymousUser, which is very un-DRY (IMHO) This patch allows the creation of a user with the username BuiltinDjangoAnonymousUser, and will return an instance of that User (if it exists) instead of the AnonymousUser class. I added checking in the actual user model for this special user so that it will still return the proper values for is_authenticated, and is_anonymous, and so that noone could login as the special anonymous user. I also added a management command to create the new Anonymous User, and a signal listener to ask if you want to create one when you first install the Auth app. http://code.djangoproject.com/ticket/9444 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: AnonymousUser that you can set specific permissions for
On Fri, Oct 24, 2008 at 8:49 PM, James Bennett <[EMAIL PROTECTED]> wrote: > Seeing as you can already create a special user object in your own app > and treat it as "the" "anonymous" user, I don't see any benefit from > this, as I told you when you mentioned this in the #django-dev > channel. Plus, it's unlikely that everyone who wants a "real" > anonymous user will have exactly the same needs you do, which makes > this even more a candidate for being your own code in your own app, > rather than everyone's code in everyone's copy of Django (this is a > huge bikeshed argument waiting to happen, in other words). I understand that and it is likely what I will end up doing, but I figured I would throw my proposal and patch up here for people to debate so I could see what other potential use cases might not be met by this so that I can try and make my AnonUser model work for as many people as possible. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: AnonymousUser that you can set specific permissions for
On Sat, Oct 25, 2008 at 2:59 AM, David Cramer <[EMAIL PROTECTED]> wrote: > > I think being able to specify permissions for the AnonymousUser is > useful, but hacking this in as a row in the database for User is not > the right approach. > > I'm +1 for the ability to give permissions to anonymous users. How would you suggest doing it then? Since creating a model that will only ever hold one item seems kind of odd to me and in order to specify permissions there needs to be some model to to assign the permissions to. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Set minimum MySQL version for Django 1.0
My web host is still using 3.32 on the majority of their servers. They just started upgrading to 5 though and plan on getting all their servers migrated by the end of the year. Though I dont use MySQL for django so I dont care what version they are using. I use PostgreSQL, which my host is running 7.19 of that Dj Gilcrease OpenRPG Developer ~~http://www.openrpg.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Feature reviews for 1.1
Just a note about Auth-01, the particular solution I posted is only the first and fastest method I could think to implement the feature of being able to set permissions for the anon user. I care less about the implementation details then I do about the feature. Dj Gilcrease OpenRPG Developer ~~http://www.openrpg.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Proposal: add static_fields to ModelAdmin
I realize this wont get a lot of attention right now do to work on 1.1, but I figured I would mention it now so I can get opinions before I start any actual work on the idea The editable keyword in model fields as an administrative feature I feel should not be defined in the model, it is still fine for ModelForms. What I propose is a static_fields list, similar to search_fields in the Models Admin class. There would be one major diffrence between a static_field and how editable=False acts now and that is the ability to display the data in the admin UI. Right now a field with editable=False cannot be part of the admin fields list, which is rather anoying when you wish to see what the data is but dont want it to be editable via the admin UI. Any field (except FileFields) that is in the admin fieldset (weather set directly set or by introspecting the model) and in static_fields would render as a normal form field, but have the readonly attribute set. FileFields would just provide the link to the file with the target="_blank" attribute so the file could be downloaded or viewed but not modified. This will allow field data to be viewed but not modified and remove the only admin feature that remains in the Model definition. The only argument against this I can think of is that by relying on the readonly attribute of a form field it would be possible for someone to remove that attribute via a greasemonkey script or something similar, thus allowing the data to actually be modified. But if you think people you give administrative access to your site would do that then maybe you shouldn't give them administrative access, and it should be possible to ensure that when the form is submitted any field that is in the static_fields list is just ignored when saving the model. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Dynamically Altering Settings
If I am reading the code right you should be able to set all three settings directly in your middleware. You just need to define TEMPLATE_DIRS = [] in your settings file and make sure the other two are not defined at all. http://dpaste.com/hold/96109/ And as long as that middleware is set as the first one in your middleware list it should function how you want --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: [GSOC] Altering the signature of Field.db_type and Field.get_db_prep_*
On Thu, Jul 30, 2009 at 5:55 AM, Russell Keith-Magee wrote: > Of course, Alex and I may have missed an obvious alternative solution > - or a use case that isn't solved by either approach. Any feedback or > alternative approaches we may have missed are most welcome. It's been a while since I did anything with custom fields, django.contrib.contenttypes.generic.GenericRelation has a reference to the model it is attached to that is created in def contribute_to_class(self, cls, name):. I am going to assume that in the multi-db code the Model has a reference to the connection it is supposed to use, so why not add the reference to model to the Field class, then any time you need connection info you get it from the parent model? class Field(object): ... def contribute_to_class(self, cls, name): self.model = cls ... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Ticket #6705
On Tue, Mar 4, 2008 at 10:59 AM, James Bennett <[EMAIL PROTECTED]> wrote: > Thoughts? he cant do something like http://dpaste.com/38006/ ? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
