I read from "1.2 beta" thread that this might make it to the 1.2 beta
of Django, any status on that? Is someone trying to commit the patches?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develo
Hi!
I was wondering what is the status of branch branches/soc2009/http-
wsgi-improvements (
http://github.com/django/django/tree/soc2009/http-wsgi-improvements
)? I'm personally interested one bug it fixes, mainly ticket #2131
( http://code.djangoproject.com/ticket/2131 )
The branch seems to be
I've been trying to figure out the state of class based generic views
without success. (Though syndication views seems to be class based now
at least.)
If I figured out correctly the class based generic views does not land
on 1.2, so I was wondering are they planned to 1.3? Those are rather
import
On 11 touko, 03:37, Russell Keith-Magee
wrote:
> show us the code!.
>
> [1]
> http://github.com/jacobian/django/tree/class-based-generic-views/django/views/generic2
Yes, well. I have been in slight assumption that the above code is the
one that will be merged. Though if it needs to be improved,
On 13 touko, 03:14, fitzgen wrote:
> * How to deal with state and self. I have written an instantiator that
> wraps the view class and instantiates a new instance of the class for
What about class method "instantiator"? It does have one extra nicety,
it does not need to be imported as one imports
If I seem lunatic, that is just because I just discovered Django.
On 31 tammi, 06:24, Nate Straz <[EMAIL PROTECTED]> wrote:
> With this method we could support the old style of Admin class in
> models and whatever new way we want for extending the ModelAdmin class
> using admin.py in each app.
I've made this snippet: http://www.djangosnippets.org/snippets/164/
that I strongly believe should be part of Django (with little
polishing of course).
If newforms admin started to use that, we could give all views an
ability to use fieldsets too. That could be inserted to same file as
BaseForm o
Modularity of edit inline? Any better?
Currently:
models.ForeignKey(Other, edit_inline=models.TABULAR, parameters...)
obiviously is a big waste of OO abilities,
instead something like, the OO way:
models.ForeignKey(Other, edit_inline=models.TabularInline(parameters))
were much better. (I know it
Hi!
I'm on a monumental task here, I've decided to get one Django instance
running hundreds of websites.
I've run in to couple of shortcomings with django:
1. Global SITE_ID does not work since some requests belong to
different site. I've created middleware that adds request.site_id
based on hos
Hi!
I've started another thread since I was oblivious about this one.
One thing I noticed in my early experimentation is that caching Site
objects is a bit of waste. I don't know what is the overhead for
caching Site objects compared to just IDs but I suppose when we get to
hunderds of sites and
This is the stuff I've come up on first try few days ago:
Here is my current cache implementation: https://gist.github.com/795135
And here is my middleware: https://gist.github.com/795138
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
For the project which I plan to use this is such that all sites could
share same INSTALLED_APPS, but it would be truly awesome if full
settings were possible for each site.
On Jan 26, 5:10 pm, Lorenzo Gil Sanchez
wrote:
> I suggest to have a look to www.reviewboard.org since they have solved
> th
On Jan 26, 5:20 pm, Xavier Ordoquy wrote:
> Given the title, I would feel bad for the sysadmin if there was hundreds of
> setting files with just the site id within ;)
Ha, single file per site :) I would change to that any day.
The current system in place is following: ~60 (and growing) website
On Jan 26, 6:56 pm, FeatherDark wrote:
> Greetings huge django developer list,
> I just wanted to mention, this method totally works for me, I call it
> "Skinning"
>
> In the templates folder I have a file called "base.html'
> Inside that file is only 1 line:
> {% extends request.META.HTTP_HOST|cu
I think I've found the necessary tools making the Django login to work
per site basis:
1. Create own login view that calls the auth backend with
authenticate(site_id, username, password)
2. Create own auth backend that takes site_id, username and password
(also checks permissions by site)
3. *)
permissions (UserSite and GroupSite):
class UserSite(models.Model): user, site, is_superuser, is_active,
permissions
This is pretty pluggable, no patches to django (yet) except one
considering testing:
http://code.djangoproject.com/ticket/15179
On Jan 27, 5:16 pm, Jari Pennanen wrote:
> I think I
Graham is correct.
I pointed out this in my reply to reviewboard method which works just
like Jjdelc proposed, and that is incorrect way.
So simply put: Changing settings object in middelwares is WRONG. If
one changes the settings object before or after request, it will be in
intermediate state i
Certainly something new for me.
That does look like a rather cool. Essentially if that works one could
save even the request object to thread "global" and it would be
accessible anywhere.
It would solve many problems, such as django's authentication
middleware's shortcoming where it does not pass
bably have to be aware is that if this
make_tls_property is not done early enough my apps must not rely on
this method:
SETTING = getattr(settings, 'MYAPP_SETTING', 'default')
especially if the use SITE_ID, MEDIA_URL or MEDIA_ROOT.
On Jan 29, 2:55 pm, Jari Pennanen wrote:
>
Hi!
I suggest you to look on to this _patch_setattr I cooked. I noticed
that it is also necessary to patch the __setattr__ of the settings
object in order to allow changes to the settings.SITE_ID again.
Following test would fail after TLSProperty:
settings.SITE_ID = 42
assert settings.SITE_ID ==
On Jan 30, 7:20 am, Russell Keith-Magee
wrote:
> On Sat, Jan 29, 2011 at 8:55 PM, Jari Pennanen
> wrote:
> If an engineer came to their supervisor with a problem and said "I'm
> going to fix this problem with a global variable", they would be
> soundly beaten
With globals:
No patches to Django required. Flatpages, media urls, media roots can
be customed by request and works without single problem. Mostly
because settings are used like settings.SITE_ID etc. and not like
getattr(settings, 'SITE_ID') in apps.
If Django ever is patched to work without thi
In above I have error:
authbackend.save(session, user) -> bool
authbackend.load(session) -> user object
should be:
authbackend.save(request, user) -> bool
authbackend.load(request) -> user object
Since getting site id from request is the thing I need to do and save
it to session.
--
Y
Notice that I never suggested *django* to implement thread local hack,
it just allowes me to continue. The thread local hack is just that
hack, it hides the real problem for now since Django does not support
the stuff I need it to.
Settings object should be considered mainly read-only, if the stu
On Jan 31, 8:30 am, James Hancock wrote:
> 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 arr
On Jan 31, 8:27 pm, Carl Meyer wrote:
> On Jan 31, 1:49 am, Xavier Ordoquy wrote:
>
> > 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
>
> Exactly!
I've not supported a
I opened up a ticket http://code.djangoproject.com/ticket/15215 in
order to make the class based view permission checking easier.
I don't know do other think that they need to be easier to check, but
I think following API would be simple:
class ProtectedView(TemplateView, ForbiddenMixin):
tem
I noticed that it is safer to subclass ForbiddenMixin from View
because of MRO: https://gist.github.com/808516
If it is subclassed from View, then above would throw error and one
could not even define them in wrong order: AuthedViewSecond(View,
ForbiddenMixin):
--
You received this message becau
Here is now subclassed from View, and checked that overriding works:
https://gist.github.com/809208
--
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
"Meh - this seems like reinventing a syntactic wheel to me. Python
2.6
has class decorators." - Russel
Why to use decorators? They cannot be overridden neatly in subclasses,
see my above gist about this subclassing.
--
You received this message because you are subscribed to the Google Groups
"D
On Feb 3, 2:16 pm, Russell Keith-Magee
wrote:
> On Thu, Feb 3, 2011 at 4:47 PM, Jari Pennanen wrote:
> The pair of Ls in my email address aren't just there for show. Russell. Two
> Ls.
I'm terribly sorry, that was unintentional.
But I would be happy for class decorators to
subclasses is a good to have.
On Feb 3, 6:15 pm, Lukasz Rekucki wrote:
> On 3 February 2011 16:09, Jari Pennanen wrote:
> If they're not decorators, then that's even worse, 'cause you need to
> duplicate all existing permission checking decorators.
In fact current decor
On Feb 3, 7:49 pm, Łukasz Rekucki wrote:
> On 3 February 2011 18:06, Jari Pennanen wrote:
>
> > If everyone is happy with class decorators we should do it. But bear
> > in mind that removing the ability to override them practicly means
> > that only Final class should
WTForm is simple implementation built on top of existing (new)forms to
help create fieldsets, and by judging django snippets alone one can
see it's a huge hole in Django. Everyone has wondered why the heck
doing those fieldsets is such a pain when in admin it is super easy,
and it turns out the Dj
Hello!
class City(models.Model):
# ...
class Person(models.Model):
# ...
hometown = models.ForeignKey(City, null=True, blank=True)
class Book(models.Model):
# ...
author = models.ForeignKey(Person)
# Can I cache Persons and Books too when getting City? After all there
is ba
Found out that it doesn't work.
I think this should be documented that backwards relationships does
*not* work in select_related, since I see no reason why it couldn't
work, it might be tricky to implement, but I think it should be
doable.
If it were documented, someone might get idea to improve
On Mar 24, 3:08 am, Malcolm Tredinnick
wrote:
> Seriously, if we documented everything that wasn't possible with Django,
> the documentation would be a couple of million words long. There's
> nothing that says select_related() does work with reverse relations and
> if people are going to make ass
37 matches
Mail list logo
