Suggestion: make auth login view more dynamic
I couldn't find an existing ticket but I'd like to suggest a change to make the
basic auth view more dynamic (I'm not fond of hardcoded context variables :-))
change:
def login(request, template_name='registration/login.html',
redirect_field_name=REDIRECT_FIELD_NAME,
authentication_form=AuthenticationForm,
current_app=None, extra_context=None):
to:
def login(request, template_name='registration/login.html',
redirect_field_name=REDIRECT_FIELD_NAME,
authentication_form=AuthenticationForm,
current_app=None, extra_context=None, form_name='form'):
and obviously:
context = {
form_name: form,
redirect_field_name: redirect_to,
'site': current_site,
'site_name': current_site.name,
}
Kind Regards,
Hedde van der Heide
--
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: Multi-tenant Django
I wanted to point out that Mezzanine doesn't actually just use django.contrib.sites. Mezzanine uses django.contrib.sites and thread locals. The way it is set up example1.com and example2.com can both be driven by the exact same django instance but have different content. The third paragraph in the first post of this thread explains a bit more about how it works: http://groups.google.com/group/mezzanine-users/browse_thread/thread/e173dee4c683e05c On May 9, 8:15 pm, Brett H wrote: > Alec, > > Mezzanine is using standard django.contrib.sites. Nothing special > there. The main issue with the sites framework is that each site runs > using a separate process and settings, so the resources can add up > depending on how you setup the stack, and managing the tenants becomes > the issue as they grow in number. Apache with modwsgi using self > destructing daemons is the best solution here. > > Untilhttps://code.djangoproject.com/ticket/15089is resolved IMHO > django-hosts is currently the best lightweight solution for multi- > tenancy requirements in django, but not useful with a project like > Mezzanine I'm afraid. > > https://github.com/ennio/django-hosts > > cheers, > > Brett > > On May 9, 1:02 pm, Alec Taylor wrote: > > > > > > > > > Dear Django-developers, > > > I've been using Django for a few months now, and recently—for > > different projects—started using the web-framework: web2py[1], and the > > Django project: mezzanine[2]. > > > Both advertise as being multi-tenant solutions[3][4]. > > > Would it be possible to extend Django to meet this use-case? — Or have > > I overlooked something and is this possible already? > > > Thanks for all information, > > > Alec Taylor > > > [1]http://www.web2py.com/ > > [2]http://mezzanine.jupo.org/ > > [3]https://groups.google.com/forum/#!topic/mezzanine-users/4XPe5MaD4Fw > > [4] PyCon 2012 > > talk:http://youtu.be/M5IPlMe83yI?t=5m32shttp://dl.dropbox.com/u/18065445/S..., > > see yt for more info) -- 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: Multi-tenant Django
On May 23, 3:16 am, Anthony Briggs wrote: > I did a similar thing for some of my projects - the problem is that you > can't reuse any non-multitenant apps without hacking the multitenant stuff > in first, ie. it's a bit of a hack, plus it makes things harder to maintain > going forwards. > > One database per tenant should (in theory) make life much simpler. One schema per tenant would also be pretty good. It makes it much easier to do cross-db queries, or use a public schema for common stuff. This should be doable if/when the support for database schemas is included. I got pretty far in that feature in ticket #6148, but it turns out to be pretty complex to support introspection and creation on all the databases for both production and testing. So, it remains to see if we want to add all that complexity. Still, multitenancy support seems to be one use case where the database schemas support could be very useful in Django. - 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.
Re: Redesign of djangoproject.com?
Hi everyone, I saw this on HackerNews(news.ycombinator.com) and wanted to contribute. Here is my mockup: http://i.imgur.com/dSMSJ.jpg With the design, I focused on keeping the look extremely clean, professional and minimalistic. The content is based on that of the current site. The mockup may seem a bit lacking in color, but adding eye-catching icons for the features, and the screens for the "built with Django" section will add sufficient color to liven up the design. On wider screens, the blog posts will appear in a siderbar to the left of the features list. If you guys like it, email me at inl...@gmail.com, or reply here. You can check out my previous work at madebyargon.com. Some of you may have seen the redesign I did for VideoLAN (videolan.org) which receive a positive reaction from the open-source community surrounding VLC. Thanks. On Saturday, April 28, 2012 2:05:27 PM UTC+6, Russell Keith-Magee wrote: > > Hi Dana, > > I completely agree. I've been trying to get a redesign of > djangoproject.com going for quite some time under the auspices of the > Django Foundation. As you can see from the lack of changes, you can see > that I haven't been particularly successful :-( > > The fundamental problem is that we have plenty of coding talent at our > disposal, but not as much design talent. That's not to say that there > aren't many talented designers in our community -- there are -- it's just > that they're all very busy. We've approached several people in the Django > design community asking them to help out, and some have even made done some > initial work. However, redesign of a high-profile site like > djangoproject.com is a big job, and nobody has been able to spare the > time to bring the job to completion. > > So - at this point I'm open to any offers. I want to avoid design by > committee -- ideally, I would like to pass this off to a single person (or > a small group) and give them complete control over design process. I'm not > completely sure how to organise who gets this role -- suggestions are > welcome. > > If you (or anyone else) is interested, drop me a line and I can give you > the design brief we've been working with. > > Yours, > Russ Magee %-) > > > > On Saturday, 28 April 2012 at 3:22 PM, Dana Woodman wrote: > > > So now that Django is being moved to Git/Github (which is awesome!), > maybe it would be a good time to think about a revamped home page for the > project ala djangoproject.com (http://djangoproject.com)? > > > > Obviously this is no small undertaking and would be potentially > contentions as to what would be the proper path, but I feel (and I don't > think I'm alone) that djangoproject.com (http://djangoproject.com) could > use a bit of a facelift. > > > > I have some idea of my own as to how this could be accomplished and I'm > sure there are a ton of others out there with great ideas as well. Maybe we > could open up some discussion on this idea? > > > > Forgive me if this has been proposed before as I'm new to the group! > > > > Cheers, > > Dana > > > > -- > > 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/-/g8ngEnVG_EsJ. > > To post to this group, send email to > > django-developers@googlegroups.com(mailto: > django-developers@googlegroups.com). > > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com (mailto: > 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 view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/redpIwTY8KMJ. 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: Multi-tenant Django
I played around a bit with using this, and got something quite workable going on. https://bitbucket.org/schinckel/django-multi-schema It's really only an exploration, but does show that it can be done. The problems actually really only got hard once you factor south into the equation. There are a few little hacky things that needed to be done (like setting the search path), and it probably only works on postgres, but as a concept I still feel like it has legs. There are also a couple of other approaches out there, too. Matt. On Thursday, May 24, 2012 3:36:58 AM UTC+9:30, Anssi Kääriäinen wrote: > > On May 23, 3:16 am, Anthony Briggs wrote: > > I did a similar thing for some of my projects - the problem is that you > > can't reuse any non-multitenant apps without hacking the multitenant > stuff > > in first, ie. it's a bit of a hack, plus it makes things harder to > maintain > > going forwards. > > > > One database per tenant should (in theory) make life much simpler. > > One schema per tenant would also be pretty good. It makes it much > easier to do cross-db queries, or use a public schema for common > stuff. This should be doable if/when the support for database schemas > is included. I got pretty far in that feature in ticket #6148, but it > turns out to be pretty complex to support introspection and creation > on all the databases for both production and testing. So, it remains > to see if we want to add all that complexity. Still, multitenancy > support seems to be one use case where the database schemas support > could be very useful in Django. > > - 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/-/YNGondmretoJ. 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: Redesign of djangoproject.com?
On 24 May 2012 02:36, Ashraful Sheikh wrote: > Hi everyone, > > I saw this on HackerNews(news.ycombinator.com) and wanted to contribute. > Here is my mockup: http://i.imgur.com/dSMSJ.jpg > > With the design, I focused on keeping the look extremely clean, professional > and minimalistic. The content is based on that of the current site. The > mockup may seem a bit lacking in color, but adding eye-catching icons for > the features, and the screens for the "built with Django" section will add > sufficient color to liven up the design. On wider screens, the blog posts > will appear in a siderbar to the left of the features list. > > If you guys like it, email me at inl...@gmail.com, or reply here. You can > check out my previous work at madebyargon.com. Some of you may have seen the > redesign I did for VideoLAN (videolan.org) which receive a positive reaction > from the open-source community surrounding VLC. > You really might want to read this thread before posting any mockups - especially Russell's comments. Just to point out one problem: where is the "Code" or "File a bug" link ? If someone wants to contribute to Django in some way: code, doc fixes, translation, money for DSF, etc., the site should make it easy to find the necessary information for that to happen (like a link bug tracker, *link to github*, link to Transifex and a contact to DSF). "Download" is really not the most important link these days. Just my 2 cents. -- Łukasz Rekucki -- 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.
