Re: ForbiddenMixin for Django?

[Jari Pennanen]

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 define them.

That could lead to following annoying situations: Base classes could
e.g. enforce using some requirement for User.user_permission and
subclass could require using per object permission. What would happen
now? The programmer could not subclass from that class only because
the permissions checking is enforced in super class but otherwise a
good class, not exactly a good solution.

So I think the overriding ability in subclasses is a good to have.

On Feb 3, 6:15 pm, Lukasz Rekucki <lreku...@gmail.com> wrote:
> On 3 February 2011 16:09, Jari Pennanen <jari.penna...@gmail.com> wrote:
> If they're not decorators, then that's even worse, 'cause you need to
> duplicate all existing permission checking decorators.

In fact current decorator permission checking mechanism is wrong, it
does two things in one function: Checking permissions from request
(what I propose to separate) and being decorator at the same time.
They break the principle of one function one task, and should be
breaken apart to checker functions and decorators. Similarly as
validator functions are separated and reusable.

This is what I said in my ticket that *checker* functions are reusable
in decorators (not otherway around.)

> things like `template_name` or `model` just overwrite whatever was
> previously defined in the base classes. In case of permission checks,
> you will most likely want to *add* checks, not overwrite. Also, if I
> have 2 views/mixins that do some checks (which most likely are
> required for proper operation of those views/mixins), then if I
> inherit from both, my subclass should do all those checks, not only
> part of them.

Making the attribute to *add only* is possible (but I don't support
that because of need to override I said above), by iterating over
classes (in __mro__*) and combining the checker functions to one list.
However I find that would be odd behavior for class/instance
attribute. Also programmer should be able to remember all the checker
functions in all superclasses, and the overriding the earlier values
becomes impossible (or requires other way to do it).

*One can iterate over classes in mro order using e.g. inspect.getmro().

-- 
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: ForbiddenMixin for Django?

[Jari Pennanen]

On Feb 3, 2:16 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Thu, Feb 3, 2011 at 4:47 PM, Jari Pennanen <jari.penna...@gmail.com> 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 too, as long as it is
simpler.

> To my mind, this isn't quite the same as setting template_name. That's
> a simple configuration issue, not something that fundamentally alters
> view behavior. To reinforce the point -- as an alternative to
> specifying template_name, you can override the function
> get_template_names() which programatically returns the right template.
> It would strike me as strange for the list of decorators to be applied
> to a view to be configured in the same way. Yet it would be
> contradictory to have some class variables extendable by function, but
> not others.

This forbidden_checks is not list of decorators, just functions that
checks the request/input if the view is allowed to view. Secondly why
couldn't there be get_forbidden_checks() getter too if that is the
problem?

I personally don't find this behavior surprising. If there really is
something fundamentally different with forbidden_checks and other
class attributes like model, queryset, template_name,
context_object_name, ... then there has to be a way to define the
difference.

I can't see those other attributes any less important, shit will break
if one changes them unless changing other parts too (usually).

-- 
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: ForbiddenMixin for Django?

[Jari Pennanen]

"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 
"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: ForbiddenMixin for Django?

[Jari Pennanen]

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 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: ForbiddenMixin for Django?

[Jari Pennanen]

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 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.

ForbiddenMixin for Django?

[Jari Pennanen]

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):
template_name = 'secret.html'
forbidden_checks = (login_required,
has_perms('auth.change_user'),)

forbidden_checks is list of functions (request, *args, **kwargs) ->
bool, has_perms is thus function that returns function.

This API would also allow to *override* the checks in subclassed
views, even make them empty again if needed.

I have not yet tried to create ForbiddenMixin but I don't think it
should be too difficult.

-- 
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

[Jari Pennanen]

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 arbitrary settings, only SITE_ID, MEDIA_URL and
MEDIA_ROOT. These alone should allow to do sites like Weebly etc.

In fact I directly oppose multinenacy for e.g. INSTALLED_APPS -- it
can be solved later, even these three settings will take a huge effort
to get support.

> 1) Using threadlocals, as discussed above.

Yes, thread locals are great hack for SITE_ID, MEDIA_URL and
MEDIA_ROOT meanwhile, other settings I have not studied.

-- 
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

[Jari Pennanen]

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 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.

Thats in my proposal implementation "2. Using middleware"
http://ciantic.github.com/multisited/README.html

What comes to documenting which settings can be changed runtime, it
sounds madness. Is there any settings like that? I can't think of any,
all of the relevant settings will suffer threading issues as soon as
changed in middleware (unless used local thread trick, and that is not
advised). There is no reason one should change settings attributes on
runtime unless in tests.

-- 
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

[Jari Pennanen]

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 stuff
saved to there is not read-only, then it probably is in wrong place.

I've put my *non* thread local proposal here: 
http://ciantic.github.com/multisited/README.html
I would like comments on that from Russ or someone who has influence
on Django core.

-- 
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

[Jari Pennanen]

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.

-- 
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

[Jari Pennanen]

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 this thread local trick, I
can very simply change it to use the interfaces I speaked about.
*Using* these interfaces I proposed (instead of globals) is simple,
but patching Django to use them is slow process. I'm willing to work
on it, but I don't think there is enough momentum to make for instance
the:

  get_request_media_root(request)
  get_request_media_url(request)

I proposed.

-- 
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

[Jari Pennanen]

On Jan 30, 7:20 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Sat, Jan 29, 2011 at 8:55 PM, Jari Pennanen <jari.penna...@gmail.com> 
> 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 by any supervisor worth their salt. Somehow, because
> the name has been changed to "threadlocal", global variables have
> suddenly become acceptable.
>
> Every single problem associated with using global variables exists
> with threadlocals -- and then a few more. They *can* be used
> successfully. However, in almost every case, they can also be avoided
> entirely with a good dose of rigorous engineering.

Without the globals:

What are the chances to get the load of patches to Django which would
be required to implement following:

  get_request_site_id(request)
  get_request_media_root(request)
  get_request_media_url(request)

Even these would require big patches, and thats not going to happen,
it literally takes *years* to get those interfaces to Django and make
all the apps working with the above interfaces even though they are
simple changes.

On top of that there had to be at least a second auth backend method
(if not altered completly see below):

  get_user_request(user_id, request=None)

And replace the django.contrib.auth.get_user() backend get_user() call
with get_user_request()

-
Altering the auth backend role.

In fact I think this module level django.contrib.auth.get_user(),
login() is currently wrong way to do things in the first place IMO, it
cuts out the authentication backend all together. It would be simpler
to imagine this login / get_user as following:

- Saving the user to request.session (currently handled by the module
level login(), and backend.authenticate())
- Loading user from request.session (requests after login) (currently
handled by the module level get_user(), and backend.get_user())

There is no simple way one could define own behavior for this saving
and loading the user to session in auth backends. That simply is odd
to me. It sounds like the thing I would like to define myself.

If there were a way to define saving and loading user one could do
cool stuff like:

1. per site login system (saving site_id to session during saving and
fetching it from session during loading)
2. during login caching of user permissions to session (no need to hit
database after login for permissions!)

One could define the saving and loading of user to session in
authentication backend with simple methods like:

  authbackend.save(session, user) -> bool
  authbackend.load(session) -> user object

Then:

- django.contrib.auth.login would become the caller for
backend.save(session, user) of course the login() could still use the
backend_session_key and user_id there
- django.contrib.auth.get_user would become the caller for
backend.load(session)

-- 
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

[Jari Pennanen]

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 == 42

and they all failed after using make_tls_property, this is because of
funny LazyObject Django uses.

So I came up with _patch_setattr, see gist:
https://gist.github.com/802020

-- 
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

[Jari Pennanen]

Sorry about second post but I'm so thrilled about this thread local
approach! Thanks Waldemar.

This changes everything, EVERYTHING.

I can just do:

settings.__class__.SITE_ID = make_tls_property()
settings.__class__.MEDIA_URL = make_tls_property()
settings.__class__.MEDIA_ROOT = make_tls_property()
# This does not have to be in settings object but for the sake of
example:
settings.__class__.REQUEST = make_tls_property()

After which I create own middleware that sets them for each request.
Then I can just access the values with settings.REQUEST,
settings.SITE_ID ...

Only thing I probably 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 <jari.penna...@gmail.com> wrote:
> 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 request object to the
> auth backend's get_user() which is sole reason I had to write *own*
> authentication middleware for per site basis.
>
> Another unrelated thing I'm now wondering is the django.core.cache, is
> it faster than my simple dict cache? That is { 'example.com' : 5, ...}
> should I change my caching to this django.core.cache... I'll have to
> study this further.
>
> On Jan 29, 10:21 am, Waldemar Kornewald <wkornew...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Hi,
> > it's possible to manipulate the settings object in a thread-safe way. 
> > Here's our dynamic site 
> > middleware:https://bitbucket.org/wkornewald/djangotoolbox/src/535feb981c50/djang..
>
> > As you can see, it makes SITE_ID a thread-local property which has a 
> > different value for every thread.
>
> > Hope this helps someone.
>
> > Bye,
> > Waldemar
>
> > --http://www.allbuttonspressed.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 
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

[Jari Pennanen]

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 request object to the
auth backend's get_user() which is sole reason I had to write *own*
authentication middleware for per site basis.

Another unrelated thing I'm now wondering is the django.core.cache, is
it faster than my simple dict cache? That is { 'example.com' : 5, ...}
should I change my caching to this django.core.cache... I'll have to
study this further.

On Jan 29, 10:21 am, Waldemar Kornewald  wrote:
> Hi,
> it's possible to manipulate the settings object in a thread-safe way. Here's 
> our dynamic site 
> middleware:https://bitbucket.org/wkornewald/djangotoolbox/src/535feb981c50/djang...https://bitbucket.org/wkornewald/djangotoolbox/src/535feb981c50/djang...
>
> As you can see, it makes SITE_ID a thread-local property which has a 
> different value for every thread.
>
> Hope this helps someone.
>
> Bye,
> Waldemar
>
> --http://www.allbuttonspressed.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 
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

[Jari Pennanen]

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 if there is concurrent request and wreaks havoc in
multithreading.

Also there is a additional problem with that, there are apps that uses
settings in their __init__.py like this:
  SETTING = getattr(settings, 'MYAPP_SETTING', 'sensible default')
these would not work afterwards either.

Though I'm not too worried about apps since I need to write most of
the apps myself anyway since there are very little apps that support
sites framework the right way.

Either way my current method does not include hundreds of files, just
database entries in Site, which are cached:
https://gist.github.com/795135
https://gist.github.com/795138

-- 
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

[Jari Pennanen]

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|cut:':'|add:'.html'%}

request.META.HTTP_HOST is coming from Client. "Trust but verify", you
are not verifying this. It could pose a security risk. One could send
a request with malicious Host header and make the site retrieve
different template. This is not a serious issue, since you probably
don't have templates that would wreak havoc.

Why don't you create own template context processor that would add the
verified HTTP_HOST to template context? Then you could do just

{% extend MY_VERIFIED_HTTP_HOST %}

See:
http://docs.djangoproject.com/en/dev/ref/request-response/#django.http.HttpRequest.META
http://docs.djangoproject.com/en/dev/ref/templates/api/#writing-your-own-context-processors

-- 
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

[Jari Pennanen]

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) websites
of Joomla with symbolic links all littered so one can "control all
sites" from one place. On top of that cake each site has own database
tables, thats freaking nightmare.

On next two years, I can expect the number of sites to rise about 500.
I have to blow the whistle long before that if I can't come up a
better solution than this Joomla hack.

-- 
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

[Jari Pennanen]

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
> this problem a long time ago.

Hey thanks!

Here is the relevant code (in order of discovery):
https://github.com/reviewboard/reviewboard/blob/master/reviewboard/settings.py
https://github.com/reviewboard/reviewboard/blob/master/reviewboard/admin/middleware.py
https://github.com/reviewboard/reviewboard/blob/master/reviewboard/admin/siteconfig.py
(see load_site_config)
https://github.com/djblets/djblets/blob/master/djblets/siteconfig/middleware.py
(some dynamic settings stuff)

Although I would love to see per request settings object, but this is
not a way to go. I mean (judging fast) it seems like their
implementation is not thread safe: On each request it patches the
settings object with own stuff. If the request is not fully served
until next request comes, the settings object might get mangled too
early.

On the other hand if all code were to use get_settings(request=None)
instead of django.conf.settings that could work. If we are not trying
to achieve thread safeness, then probably one could open up enough
workers so that each django instance would serve single request at a
time.

Maybe they don't use multithreading in reviewboard?

-- 
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: contrib.sites and multitenancy

[Jari Pennanen]

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 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: contrib.sites and multitenancy

[Jari Pennanen]

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 most requests need *only the site id* it could
be significant.

Point is that most of the time view needs only site_id for filtering.
(sites__id__exact=site_id)

So currently I'm caching only site ids to dict by host name like this
(on first time it populates the cache from Site.objects.all()):

_CACHE_SITEIDS = {
  'example.com' : 2,
  ...
}

And my MultiSitedMiddleware does pretty much this (following code does
not include function getters/setters to simplify):

request.site_id = _CACHE_SITEIDS.get(request.META.get('HTTP_HOST',
''), settings.SITE_ID)

So I propose to implement get_current_site_id(request=None) and
get_current_site(request=None) if middleware is out of question. If
request is not given the return settings.SITE_ID or current site
object. (get_current_site should *not* cache, it gets the Site object
on demand, it is very to need the site *object*)

I've reviewed my approach and so far only thing I'm missing is that I
also need to cache for settings.MEDIA_ROOT and MEDIA_URL and MEDIA[1]
by site (Site objects does not support this, so I'm going to do
extended Site model that creates a support for that). So I probably
will implement some additional cache getter get_media(request=None)
that returns tuple (media, media_url, media_root)

([1]Notice that I have one extra there "MEDIA" which is not part of
standard django, but it is just dict that initializes single Media
object (MEDIA={'css' : ...} in settings.py) that can be used sitewide.
I've found this as handy to have so I can update sitewide jquery.js
file/url from settings.py alone. Since it is per site setting I must
save it to database or somewhere and make it changable as per site
like MEDIA_ROOT and MEDIA_URL.)


On Jan 19, 10:01 pm, Carl Meyer  wrote:
> Thanks legutierr for all your work on this ticket and patch, and
> everyone for the comments. I just took some time to review the patch
> on #15089 and had a long conversation on IRC with legutierr, and
> here's what I'm thinking:
>
> It does appear that there is some code (CurrentSiteManager, for
> instance), that wants a Site object and simply cannot pass in the
> request (barring threadlocals, which is not an option for core/
> contrib). I don't think the addition of multitenancy justifies
> breaking currently-working code. So I think we need to add support for
> multitenancy (which I'm using here as shorthand for a hook that takes
> a request and returns a Site object or something compatible) in such a
> way that it is explicitly enabled by setting, and calling code that
> fails to provide the request only fails (and in a clear way) when
> multitenancy has been explicitly enabled.
>
> There's also the issue of what third-party code does when it depends
> on contrib.sites and needs an actual Site model instance, not a
> RequestSite or some other replacement. Contrib.flatpages is an example
> of this -- the flatpage model has an FK to Site, so it doesn't make
> sense for flatpages to call a method which might return a Site object
> or might return something else. It needs a real Site object. In my
> mind, this use case is why deprecating Site.objects.get_current() is
> not a good option. The current patch on #15089 deprecates
> Site.objects.get_current() and then adds a "require_site_object" flag
> to get_current_site(), but this seems backwards to me. There's already
> a well-established indicator that you want an instance (or queryset)
> of a certain model, and that is to call a manager method on that
> model. I'd rather keep Site.objects.get_current() as the supported API
> for when the calling code depends on the Site model (because, e.g.,
> it's querying the database for another model with an FK to Site), and
> get_current_site() as the API for when the calling code doesn't care
> whether contrib.sites is used or not and just wants something with a
> domain name. (I think this distinction is already somewhat implied by
> how the two methods are currently used in the Django codebase, but
> could be better documented. And they could probably named more clearly
> as well, but that ship may have sailed).
>
> In my mind, the introduction of a multitenancy hook (in the 1.4
> timeframe) could then look something like this:
>
> * Introduce a SITES_BACKEND setting, which defaults to None but can be
> set to a dotted path to a callable that takes the request and returns
> a Site object (or something else entirely, which should quack like a
> Site/RequestSite if the dev wants to use third-party code, but isn't
> required to).
>
> * Add an optional "request" argument to Site.objects.get_current(). If
> SITES_BACKEND is set and Site.objects.get_current() is not passed the
> 

One Django instance, hundreds of websites

[Jari Pennanen]

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 hostname of request.
2. User may be on multiple sites, but still should not be able to
login to other sites! (Here is a slight problem since authentication
backend assumes that username and password is only thing required.
This is not the case, I need to verify the site id from
request.site_id and check that user is listed in that site as user.)
3. MEDIA_URL could be per site basis. (STATIC_URL could be global)

This one is not a problem because django supports it already, but
anyone wondering to try out it's good to know:

4. Website manager must be able to create dynamical urlconfs (I'm now
implementing database based urlconf loading), this is rather simple
since I can inject the urlconf to request.urlconf (Django supports
this already).


Is there anyone else doing similar task? I have currently FlatPage app
running perfectly with this, only thing I needed to change from
flatpage view was following:
...
# Get request's site id, fallback to settings.SITE_ID
site_id = getattr(request, 'site_id', settings.SITE_ID)
f = get_object_or_404(FlatPage, url__exact=url,
sites__id__exact=site_id)
...

I think this SITE_ID per request is a great idea, worth thinking for
Django itself.

-- 
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: Class based generic views in 1.3?

[Jari Pennanen]

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 the view classes
already.

Then one could do: ``url(r'^path/$', ObjectView.instantiator(),
name="object_view")``

Thats mostly just syntactical sugar though, if it were class method I
would name it as create() or something...

But that is such a small detail at the moment it probably does not
matter.

-- 
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: Class based generic views in 1.3?

[Jari Pennanen]

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, I think
Jacobian could *list the problems in his implementation* so others can
try to improve on them, as he probably knows that code best.

>From that point of view, I don't see a reason in rewriting the class
based generic-views as there is already Jacobian's take on it.

-- 
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.

Class based generic views in 1.3?

[Jari Pennanen]

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
important after all...

-- 
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.

Status of branch soc2009/http-wsgi-improvements? (and ticket 2131)

[Jari Pennanen]

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 6 months old, and this makes me nervous to rely
on it, if it is not merged to trunk I'm screwed on relying on branch
that old...

-- 
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: AnonymousUser has_perm/has_module_perms function check authentication backends

[Jari Pennanen]

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-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: select_related to work with backward relationships?

[Jari Pennanen]

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 assumptions, that's their problem.

My reasoning was: If function is named "select_related", it gets all
related stuff... backward relations are as good as any relation to my
knowledge, it should get them too. To not be confusing it should be
named select_forward_relations() or something such, and if backward
relations are implemented, then create select_backward_relations() and
select_related that combines those two.

I don't know whats common consensus what "select_related" term should
contain, but I just thought it means like all related stuff.
--~--~-~--~~~---~--~~
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: select_related to work with backward relationships?

[Jari Pennanen]

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 django and
make patch for it...
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

select_related to work with backward relationships?

[Jari Pennanen]

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 backwards relation City.person_set...
City.objects.select_related() # Doesn't work.
City.objects.select_related('person_set') # Doesn't work.

# Is there some reason this doesn't work when using backwards
relations?

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

WTForm should be inbuilt to Django, and make admin & others use it.

[Jari Pennanen]

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 Django admin's way is unusable in elsewhere.
Thats the way I ended up doing my own fieldset implementation long ago
to ds, but as usual it went unmaintained.

When I had lost all will to Django ever implementing this, someone had
redone something similar, WTForm http://www.djangosnippets.org/snippets/214/
(unmaintained) with more care on details. Though it also went
unmaintained until akaihola took it to his care:

WTForm *Maintained* by akaihola found here 
http://github.com/akaihola/django-wtform/tree/master
works with Django 1.0 supposedly.

The maintained version could be added to Django, and start refactoring
parts of Django to make use of it. I mean Django admin should
definitely use this WTForm somehow, it is way more DRY than the one in
place now for the Fieldsets.

I wish people has some thoughts about this...
--~--~-~--~~~---~--~~
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: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)

[Jari Pennanen]

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 is defined elsewhere in upcoming
implementation, but the example I saw did not implement subclassing
which I think is neccessity to create it customizable, and also the
parameters is way more clear this way)

One could implement own edit inlines just by subclassing from
TabularInline/StackedInline, or from where TabularInline subclassed
itself. Currently I see no easy or sensible way to create own edit
inlines.

On 26 maalis, 00:59, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> Now that we have 0.96 out the door, I'd love to wrap up the
> newforms-admin branch, which is mostly missingedit-inlinesupport but
> works well for other cases.
>
> Joseph Kocherans was working onedit-inlinesupport, but I haven't
> seen anything checked in or heard from him about any developments.
> Joseph, are you around, and what's the status? I can happily take over
> if you're not in a position to do the implementation.
>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | djangoproject.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
-~--~~~~--~~--~--~---