Django 1.2, ManyToMany relations and legacy database support
Hi, I gave Django 1.2 a go but I had some issues with legacy database support. I have several ManyToMany relations with an intermediate model that doesn't have an id field (only 2 fields pointing on each table). With Django 1.1, I abused this snippet : http://www.djangosnippets.org/snippets/962/ As it wouldn't work with Django 1.2, I tried to got within the related.py file to adapt it but I'm a bit lost and would need some advices. My first though was to hack the create_many_to_many_intermediary_model function in order to get the intermediate class to have ForeignKeys with the right column name (with db_column) but that clearly isn't enough to make it work correctly. Now, I'm a bit lost as I don't understand how the ManyToManyField becomes a ReverseManyRelatedObjectsDescriptor... Could someone point me a direction in order to get an equivalent to db_column for the intermediate class in a many to many relation ? Regards, Xavier. -- 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: Django 1.2, ManyToMany relations and legacy database support
Hi Jacob, Thanks for your answer. I already gave intermediate models a look but I'm not feeling like defining a dozen useless model - no added value - and loosing a couple of API calls are worth just because my fields are labeled "id_fieldname" instead of "fieldname". Sorry for the annoyance. Xavier. -- 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: Django's CVB - Roadmap?
Hi,
I also had a couple of issues with Django's generic CBV.
My feeling is it raises a lot of frustration because it feels like there isn't
much missing.
I've been playing with a few solutions to work around that.
I started a small proof of concept on chaining GCBV and a few other goodies.
I'm a bit reluctant to speak about it because *I'm not happy* with the way it
currently is now.
The general idea was to be able to go as far as possible for newcomers without
modifications.
To achieve that result, I took example on what forms and models already and
used the same thing to chain mixins.
It currently what it looks like is.
1) define the mixins
class ProjectMixin(ObjectMixin):
model = Project
pk_url_kwarg = 'project_id'
def get_queryset(self):
return Project.objects.filter(members=self.request.user.id)
class BugMixin(ObjectMixin):
model = Bug
pk_url_kwarg = 'bug_id'
def get_queryset(self):
return = Bug.objects.filter(project=self.project)
2) define the views
class ProjectView(View):
project = ProjectMixin(default_mode='detail')
class BugView(ProjectView):
projects = ProjectMixin(mode='list')
bug = BugMixin(default_mode='detail')
3) define the urls
urlpatterns = patterns('',
url(r'^projects/$',
ProjectView.as_view(mode='list'),
name='projects'),
url(r'^projects/new/$',
ProjectView.as_view(mode='new'),
name='new-project'),
)
A few things to notice.
View can inherit from the others.
Objects are "namespaces" in the view. See I get project (a single object) and
projects (list of projects the user is member of) in the BugView.
You define only one view that you can specialize into list, detail, create,
update, delete (although delete isn't implemented yet).
The current state for that:
- There's no documentation (as I said, I was a bit reluctant to do that mail
because it is still a bit early)
- I recently switched from reusing the django's generic cbv to duplicating them
in the code. A few implementation details still need to be cleaned.
- I'm not happy with the way I "specialize" the mixins according to the mode
they should be in. I'm currently changing the mixin instance's heritage which I
feel is *not* what I should do. I'll probably try to do something similar to
what the forms do with BoundField
- I'm not happy with the way the "mode" is set too.
- Paginators have a semi working namespace. They *are* namespaced in the
template, but aren't for the url part, this is work in progress.
Please keep that in mind if you have a look at the current code.
The "proof of concept" is there:
https://github.com/linovia/django-alternative-views
I wrote a demo project:
https://github.com/linovia/django-alternative-views/tree/master/demo
Tests should cover most (think it was around 90%) of the custom code. Since the
inclusion of django generic cbv, it has droped but I'll see how I can play
django's test for that part (not going to rewrite existing tests).
Regards,
Xavier Ordoquy,
Linovia.
--
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: One Django instance, hundreds of websites
Hi there, I also started to have a look at something similar (ie, with settings for each site). The proposal made in the ticket wouldn't fit what you are trying to do. The current idea is to have the site id depends on the request but assumes to have only one common settings file. On the other hand, having one setting file per site where the only difference is the site id seems a bit too much overhead. Regards, Xavier. Le 26 janv. 2011 à 08:21, Derega a écrit : > On Jan 25, 4:56 pm, Jari Pennanen wrote: >> I'm on a monumental task here, I've decided to get one Django instance >> running hundreds of websites. > > I'm also on similar path here. I'm trying to build a system where > django instances running on several servers are serving hundreds of > websites. Each website has different urlconf, different templates, > different users and in some cases even different apps and features > enabled. But the codebase and settings are identical on all > instances. > > I'm still in the process of defining all requirements of the system, > but when I get those sorted out I'll start looking for solutions. This > year will be interesting, and I'm eagerly waiting what happens in > django, and if I possibly can I try to help out and participate. > > --Ilkka > > -- > 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. > -- 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: One Django instance, hundreds of websites
Given the title, I would feel bad for the sysadmin if there was hundreds of setting files with just the site id within ;) As for the urlconf, it's already possible. core/urlresolvers have a set/get urlconf that is set for the thread by the BaseHandler. Don't get me wrong, I started some work in order to have each site with its own settings. However, this seems to differ from what was done in ticket 15089. This only things that troubles me is that one shouldn't be able to set INSTALLED_APPS per site because I can't see how syncdb would perform with new apps. Xavier. Le 26 janv. 2011 à 15:51, David Danier a écrit : >> On the other hand, having one setting file per site where the only >> difference is the site id seems a bit too much overhead. > > Why not use something like this: > from global_settings import * > SITE_ID = 235 > #This also allows further changes like: > #INSTALLED_APPS = INSTALLED_APPS + ( > # 'fooapp', > #) > > I'm using something similar here, but the number of sites I need to run > with the same codebase is rather limited (unter 10). Anyways it works > well. > > In addition every site has its own python module here, so changing the > settings is just a small step...its even possible to have different > urlconfs or templates or ... > > David > > > -- > 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. > -- 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: One Django instance, hundreds of websites
Le 31 janv. 2011 à 07:30, James Hancock a écrit : > This post is getting pretty long. But I had a simple Django fix that would > make it work a lot easier for me, and might help others. (I say this because > of how I implemented it, I am working with about 60 different sites and it is > a pretty simple arrangement) > > Imagine you were able to set a site_id per request rather than relying on the > settings SITE_ID. Django would then checked for a request's site_id first and > then second check the settings one. > > It is really simple, but it would fix a lot of my problems and avoid having > to switch around the settings SITE_ID per request. Setting the requests > site_id with middleware is straightforward enough and further customizations > to the request. Changing the urls for example. > > This approach would avoid: > Threading issus, and global variables > Adding new functions to work with (Saves time and pain, documentation, > testing, releases so forth) > Doesn't break things that are tied into the Sites Framework(site-maps, > comments, etc...) > It also feels a little more DRY to me. > > Let me know if I have assumed something I shouldn't have. I don't know much > about how the current implementation and use of SITE_ID in the backend. > > Cheers, > James Hancock The thread is pretty long because there are also 2 threads in one: - one for simply changing the site_id per request - one for changing the all setting per request This being said, your solution sound pretty simple but would probably require all the applications to be rewritten. If your own applications aren't much an issue, other might be. Regards, Xavier. -- 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: proposal Meta.exclude in Form
Le 20 avr. 2011 à 05:57, Constantine a écrit : > FormModel have exclude attribute in Meta, but simple Form doesnt: > example usage: > > i need base form for editing with many fields, and derived form for > object creation with subset of fields and so i want to exclude > unnecessary fields Actually, I don't understand. If you need object creation, ModelForm is the way to go. You could also take it the other way. Base form should be the one with the smallest field set. Regards, Xavier. -- 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: proposal Meta.exclude in Form
Le 20 avr. 2011 à 09:22, Constantine a écrit : > On Apr 20, 12:26 pm, Xavier Ordoquy wrote: >> Le 20 avr. 2011 à 05:57, Constantine a écrit : > ... >> Actually, I don't understand. >> If you need object creation, ModelForm is the way to go. > unfortunately ModelForm is not suitable >> You could also take it the other way. Base form should be the one with the >> smallest field set. > You are right, base form has the smallest set. > But inheritors' field sets highly intersects and i'cant distinguish > minimum set for base class I doubt Django devs will include Meta.exclude in Form without a fully described use case. The general idea is don't include feature unless there's no other way. In your case, I can't see why you can't use a base form and extend it. Xavier. PS: I'm not a Django core dev. I just noticed this is on django dev mailing list so don't take my words as official core team answer. -- 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: [] Re: Deprecation policy for IE6
Le 9 juin 2011 à 15:06, Henrik Genssen a écrit : > the question is not - how old a browser is, but how many user it (still) has > in germany there are still 4% using IE6 - thats > half the user of Google's Chrome with 8%. > > > Henrik It looks like fewer german users are still running ie6. http://www.theie6countdown.com/default.aspx#list reports around 2% The other thing to take into account as idan said is: are those ie6 users likely to be the same that will access the admin interface ? Regards. -- 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: PHP-inspired user-friendly in-browser DJango install
Le 13 sept. 2011 à 05:44, Justine Tunney a écrit : > I agree with you that reducing the barriers to using Django is very > important. But what we need is not necessarily a web based installer, but > something to get people off the ground so they can start playing around with > Django very quickly. Back in the day (like circa 2004) the thing that really > helped me learn PHP was this program called EasyPHP which was a simple > Windows based installer that got me up and running and writing code on my > local machine in five minutes. PHP and Django installation are very different. For PHP you need a couple of things: - apache or equivalent - php module - configuration tuning - find the apache root to put your files under - a database - database modules for php and I might have missed a couple of things For Django, you'll need: - Python - Django At this point you can go ahead with the dev server and sqlite. No need to tune/configure things further. I hardly see how one can lower this further. Beyond that, what I am wondering is how much users will be able to understand how Django work if they can't do the installation. Regards, Xavier. -- 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: A policy on calling super()
Hi, I'm jumping in the discussion as I've tried - hard - to do something similar in the past. However, I'll second what has been said: mixins should be on the left side. Is there a reason your code can't be similar to: #class View(object): #def __init__(self): #print "View init" class SomeMixin(object): def __init__(self): super(SomeMixin, self).__init__() print "SomeMixin init" class MyView(SomeMixin, View): def __init__(self): print "MyVIew init" super(MyView, self).__init__() MyView() The reason why the mixin has to be left to the view isn't obvious in your example. If you need the super for the __init__ it's likely that you'll need it for other functions. As opposed to __init__ those functions will not exist in the object class. Therefore you'll end up with testing if the super has the function or not before accessing it because it'll depend on the mixins order. Regards, Xavier. Le 2 oct. 2013 à 23:56, Glin a écrit : > Sorry, I had problems to get to my google account, but finally I'm here :). > > I wrote to the ticket meanwhile, but you probably not in CC, so I paste it > here, too: > > Having this example: > class View(object): > def __init__(self): > print "View init" > #super(View, self).__init__() > > class SomeMixin(object): > def __init__(self): > print "SomeMixin init" > super(SomeMixin, self).__init__() > > class MyView(View, SomeMixin): > def __init__(self): > print "MyVIew init" > super(MyView, self).__init__() > > MyView() > > With the commented line in the View class, the method SomeMixin.__init__ is > not called, because mro chain is broken, that's the reason why I filled the > ticket. > Practical use - for exemple in current mixins, there are instance attributes > which are not defined in __init__, which is bad, code is harder to read when > new attributes pop up on unusual places, every checker like pylint displays > warning like: > W:127,8:ModelFormMixin.form_valid: Attribute 'object' defined outside __init__ > > So in ModelFormMixin, there should be __init__ which defines 'object' > attribute (self.object = None), which is IMHO more than good practice. > Also having attribute 'object' in __init__, we could avoid ugly constructions > like now (also in views/generic/edit.py): > elif hasattr(self, 'object') and self.object is not None: > > And that's example in Django itself, I bet there could be lot more in various > cases of other developers views/mixins, which are hurt by broken mro chain. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" 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/fb4b4508-99bf-4156-bbdd-f9ee4a957bbd%40googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Django developers" 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/1EEE9B02-9A6D-4318-8F49-7CF6A9F62481%40linovia.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Creating a minimal custom user model. Seems last_login is required. Should it be?
Hi, Le 21 oct. 2013 à 16:04, Tino de Bruijn a écrit : > Harry's use case is an interesting one -- his authentication is being done > entirely by an external process, so there's no need for a password field. > Yes, he could just have the password and last_login fields and not use it, > but why should he need to carry around he extra weight when Django doesn't > need it. > > @Harry, just out of curiosity, may I ask how you *do* authenticate your users? I can't speak for Harry but using the RemoteUserBackend you don't need the password nor the last_login for Django. In my case Apache did the authentication through Kerberos. Django's documentation explains more there: https://docs.djangoproject.com/en/dev/howto/auth-remote-user/ Regards, Xavier, Linovia. -- You received this message because you are subscribed to the Google Groups "Django developers" 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/2738BC7D-3E19-42EB-BD70-031E8DCE94C5%40linovia.com. For more options, visit https://groups.google.com/groups/opt_out.
