> 1) Ignore the problem. Admin works on the default database, but
> nowhere else. This is certainly less than ideal, but it would be
> sufficient for master/slave setups.
>
> 2) Use a separate admin deployment for each database. We add a 'using'
> argument to admin.Site(), and append .using() the
I've been subclassing AdminSite for a recent project, and am curious
whether there's a particular reason why the login, logout, and
change_password views shouldn't take extra_context the way most of the
other views do?
thanks,
-Nan
--
You received this message because you are su
FWIW, the previous version of Mac OS X (10.6) shipped with 2.6.1.
On Dec 23, 5:49 am, Vinay Sajip wrote:
> On Dec 10, 4:56 pm, Adrian Holovaty wrote:
>
> > I think both of these proposals are great -- start merging the Python
> > 3 work right after we release 1.4, anddropsupport for Python2.5in
t data loss if someone manages to read the docs
closely enough to update the settings but not the DB, which IMO is
something that gets addressed by calling it out very clearly in the
documentation anywhere the setting is mentioned.
Just an idea...
-Nan
--
You received this message because y
It would be really nice to be *able* to create a template loader that
can use the request object. If, for instance, you have a site that
needs to be able to change the template used based on user preferences
or based on the current Site object, it's a lot cleaner to be able to
do that once in a c