Re: runserver ignoring SCRIPT_NAME?
Thanks for your replies. Seeing as this seems to be quite specific to my current setup, I'll just try to solve this for my use case by replacing or wrapping one of the components that make up the machinery behind the runserver command. If the result is worth publicizing, I might put it up on Github; a Django ticket is probably be the wrong way to approach this. - JK -- 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/f6ca057a-5757-494e-a157-3dc7ec4d260f%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
runserver ignoring SCRIPT_NAME?
Hi all,
I'm developing a Django site that will be served in production by
nginx-proxied gunicorn. The site is mounted on a subpath, and the nginx
config sets SCRIPT_NAME to /path to facilitate this.
This arrangement works fine with gunicorn, which I've got set up in my
Vagrant environment, but usually I like to use runserver or runserver_plus
from django-extensions during development. From nginx's perspective, there
is no difference, as both gunicorn and runserver serve at 127.0.0.1:8000.
However, while the site mounts correctly to /path under gunicorn, this is
not the case with runserver. I looked into why this is, and after some time
spent in pdb discovered what looks to be the reason.
Python's simple_server.WSGIServer sets SCRIPT_NAME to '' in its
setup_environ method. Later, simple_server.WSGIRequestHandler does the
actual header processing in its get_environ method. The culprit is this for
loop contained within:
for h in self.headers.headers:
k,v = h.split(':',1)
k=k.replace('-','_').upper(); v=v.strip()
if k in env:
continue# skip content length, type,etc.
if 'HTTP_'+k in env:
env['HTTP_'+k] += ','+v # comma-separate multiple headers
else:
env['HTTP_'+k] = v
Since SCRIPT_NAME is already in env as an empty string, the first if clause
is evaluated and the nginx-provided SCRIPT_NAME is never added to the
environment, causing things to fail down the line. Later, in the else
clause, SCRIPT_NAME becomes HTTP_SCRIPT_NAME, so it is ultimately available
to Django, but get_script_name in django.core.handlers.base (in 1.6b4,
which I'm using; .wsgi in the development version) does not take it into
consideration.
At a glance, get_script_name seems like a logical place for a quick fix,
but I'm unable to see all the implications of, say, looking at
HTTP_SCRIPT_NAME there in addition to SCRIPT_NAME. To a layman, it's also
conceivable that Django's WSGIRequestHandler could extend the get_environmethod
of its base class and add some special handling for SCRIPT_NAME
there. I'm not qualified to present either option as a recommendation,
though.
Should I file a ticket for this?
- JK
--
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/a6464b3b-59c2-47f5-aa05-56eacb862fc7%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Model translation
On preview, django-datatrans looks really good, and the approach is certainly better than any of the existing implementations, including my abortive one. Still need to give it a run for its money properly to see what issues remain. Whatever they are, they're probably solvable. I'm not a betting man, but I'd be surprised if that didn't grow into the de facto model translation approach in time. I'm just glad I don't have to think about the model translation problem anymore, I was exhausted just writing that monster post yesterday :-) - JK Laiho -- 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: Model translation
> Actually there is a model translation app which uses a very similar > approach to what you describe and already covers a good chunk of your > 6 points. Huh. That's interesting, I hadn't heard of that. Will take a look. Thanks! - JK Laiho -- 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: Model translation
Oops. A mistake here: # class Animal_fi(models.Model): # name = models.ShadowingOneToOneField(Animal) The "name" field wouldn't be a ShadowingOneToOneField, but a CharField like that in the original Animal model. We'd rather need a model inheritance-like pointer field to be the ShadowO2O. - JK Laiho -- 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: Model translation
t to allow for
shadowing, but the code of related fields is too complex and I don't
understand it. But I love how the OneToOne relation between, say,
auth.User and a Customer model that inherits from it enables
transparent access to User fields through a Customer instance.
Assuming the shadowing-enabled subclass of OneToOneField was called
ShadowingOneToOneField, something like this could happen:
--
>>> class Animal(models.Model):
...name = models.CharField(max_length=255)
...trinomial_name = models.CharField(max_length=255)
>>> class AnimalTranslationOptions(TranslationOptions):
...translated_fields = ('name',)
>>> register(Animal, AnimalTranslationOptions)
# The register() function living in the hypothetical translation app
# would create an in-memory model in the app cache that corresponds to
a model
# like this, represented in the database as the animals_animal_fi
table:
#
# class Animal_fi(models.Model):
# name = models.ShadowingOneToOneField(Animal)
>>> animal = Animal.objects.create(name='Dog',
...trinomial_name="Canis lupus familiaris")
# ... time passes, the Animal instance gets a Finnish and Swedish
translation
# for the "name" field, perhaps through a custom admin interface ...
>>> activate('en-us')
>>> animal = Animal.objects.get(name='Dog')
>>> animal.name
"Dog"
>>> activate('fi')
>>> animal.name
"Koira"
>>> activate('sv')
>>> animal.name
"Hund"
>>> animal.trinomial_name # not marked for translation, so not in Swedish here
"Canis lupus familiaris"
>>> from django.ponies import pony; pony.fly()
"Whee!"
--
There would need to be a lot of descriptor action or something going
on there so that "name" would resolve to either Animal.name,
Animal_fi.name or Animal_sv.name depending on the active language.
Sadly, I'm not sure if the South migration problem described earlier
is solvable with this approach, either.
Anyway, no need to pile on me calling me stupid for all the
shortcomings that my ideas inevitably have :-). Just throwing things
out there, maybe someone smarter will be inspired to create something
that actually works.
In a perfect world, databases wouldn't suck this much as a means of
holding a variable number of translated versions of a column's data.
Instead, a TRANSLATED_VARCHAR(255) column called "name" could have any
number of translations stored along with the default language, all of
which could be 255 characters long, and you could access them with
standard syntax: "SELECT `name` IN 'fi' FROM animals_animal WHERE
id=1;" or something, and the ORM could just work with that. One can
dream. Perhaps NoSQL databases and their Django backends will make
something like this possible one day.
- JK Laiho
--
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: Proposal/RFC: assertContextContains
> Sorry, but this looks like a bit of a mess to me. It looks like you're
> cramming three different assertions into a single assertXXX method.
> I'm not sure I see why this is a good thing.
Three separate assertion statements, yes, but all of them basically
doing the exact same assertion (is something or are some things in the
context), just for different inputs. I suppose it comes down to
personal preference: If I have a method called assertContextContains,
I like to be able to give it different types of inputs (single keys, a
list of keys or a dictionary of keys/values) and just have it do "The
Right Thing" in each case. But, YMMV and varying tastes, as I
expected.
> 1) I don't see the advantage to providing an alternate implementation
> of self.assertTrue('x' in context)
Individually, it would make no sense, that's correct. But as a part of
a method that can take various different inputs and check for their
existence in the context, it's mandatory to include.
> 2) Asserting that many variables exist in the context can be done
> with multiple calls to (1), or if you want to conserve bytes, using
> self.assertTrue(all(var in context for var in ['x','y','z']))
Ah, I was unaware of the existence of the all() method. Good to know.
That alone almost completely obviates the need for a "multi-input"
method, leaving only the third form:
> 3) Asserting that key-value exists in context has been proposed
> previously - see #5333 for the proposal, and why it was rejected
Oddly, that ticket didn't turn up when I searched Trac (while #13092
did). Anyway, I tested the method against various sets of real-world
context data I had lying around in old view code, and it did work as
advertised in all of them. I'll probably keep it around in my own
toolkit just for this key-value purpose, but having read the comments
of that ticket I understand why it wouldn't necessarily make sense on
the framework level as part of the standardized, supported set of
assertion methods.
Thanks for the feedback! Live and learn :-)
- JK Laiho
(Thanks also to Paul McMillan about the deprecation info, didn't know
about that either.)
--
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: Proposal/RFC: assertContextContains
(Looks like I sort of reinvented *args and *kwargs there. Using them might look nicer, but none of the other assertion methods use them and I modeled to be in line with them.) -- 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: Proposal/RFC: assertContextContains
Having done some preliminary coding on this, I get the feeling that
the positive assertion is quite useful, but assertContextNotContains
is superfluous. Theoretically, you could use it to test that
unexpected keys don't end up in the context dictionary through the use
of locals(), but you shouldn't be passing locals() to the template
context anyway. I don't see a proper real-world use case for it here.
The code is below. I'm unsure about the method signature and could use
some input on it. The current form allows for checking a single
variable name through 'varname', one or more variable names through
'variables', and one or more variable names and values through
'dictionary'.
I've tested this code for a while now, and IMHO it feels pretty
comfortable and flexible to use as-is, allowing for mixing many
different types of template context checks without too much
complexity. Your mileage or tastes may vary, of course.
Note: for this to function, the "Ready for checkin" patch in #13092
must be applied first to allow "varname in response.context" for
ContextList objects.
If the proposal is shot down, I won't go any further. If the general
idea is approved, I'll post a proper diff into a new ticket, with any
modifications suggested here.
- JK Laiho
- - - - -
def assertContextContains(self, response, varname=None, variables=[],
dictionary={}, msg_prefix=''):
"""
Asserts that response.context contains the variable name passed in
as
``varname``, and/or each variable name specified in ``variables``,
and/or each variable name and their associated values specified in
``dictionary``.
"""
if msg_prefix:
msg_prefix += ": "
if varname is not None:
self.failUnless(varname in response.context,
msg_prefix + "The variable '%s' was not found in "
"response.context" % varname)
for key in variables:
self.failUnless(key in response.context,
msg_prefix + "The variable '%s' was not found in "
"response.context" % key)
for key, value in dictionary.items():
self.failUnless(key in response.context,
msg_prefix + "The variable '%s' was not found in "
"response.context" % key)
# String cast for e.g. a Form() in a view's template context
to
# equal a Form() instantiated in a test method
self.failUnless(smart_str(response.context[key],
response._charset) == smart_str(value, response._charset),
msg_prefix + "The value of the context variable '%s' was "
"incorrect." % (key))
--
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.
Proposal/RFC: assertContextContains
While waiting for the patch in ticket #13092 (ContextList objects do
not support "in" operator) to land in Django (hopefully by 1.3), I've
been using a trivial custom method, assertContextContains, to see if
the Context/ContextList of a response object contains a certain key or
a certain key/value pair. I've found this a lot less brittle than
looking at response contents with assert(Not)Contains.
When the fix for #13092 lands in trunk, asserting context contents
will be trivially doable like this:
self.assert_('varname' in response.context)
or, for values:
self.assert_('varname' in response.context and
response.context[varname] == somevalue)
I'd like to get some core dev feedback on whether this pattern should
be codified into official assertContext(Not)Contains methods in
django.test.testcases.TransactionTestCase. I volunteer to create the
ticket and submit the patch with the proper msg_prefix plumbing and
some docs and tests, if the idea gets traction.
With a little more work, I can probably make the method accept lists
(for lists of keys to check) and dictionaries (to check for multiple
key/value pairs) while I'm at it, though at this point the method
signature probably needs a bit more thought.
IMHO, a method like this would nicely complement the existing
assertions; they already cover what templates got rendered and what
the contents and form errors of the responses were, so an assertion to
see what contexts produced those responses out of those templates
seems like a logical addition. But what do you think? Is it worth the
effort?
- JK Laiho
--
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: Model translation
As Russell said, this is probably a bad time, but I thought I'd throw in some quick notes nonetheless. > '''django-modeltranslation''': I think this general approach is the way to go I agree that it's probably the best alternative available currently, but still not without significant drawbacks (like breaking when fields/ fieldsets are used in the ModelAdmin, and not being able to transparently query on translated fields - an issue you later mentioned). We're running a severely hacked private version/fork of django-modeltranslation in production, having added fields/fieldsets and some custom jQuery/CSS admin widgetry, but in no form that would be ready for public consumption, let alone as a basis for inclusion in Django core. Also, I was about to say that the development of django- modeltranslation seems essentially stalled, but then checked to see that the first update since March (support for admin inlines) was made three days ago, so scratch that ;-) However. I'm in the conceptual planning stages of a fresh solution to the model translation problem, one that I hesitate to say anything more about at this time since the ideas involved are not yet fully formed in my head. When Django 1.2 hits bugfix-only mode, I'll probably start tracking trunk and doing some initial prototyping against it. If it amounts to anything, you'll hear more about it next spring, hopefully around the timeframe that Russ talked about (3-4 months or so). Absolutely, positively no promises, though. Procrastinating endlessly and losing motivation altogether are a distinct possibility :-). But still, if and when the discussion pops up again later on, I might have some ideas and/or code to share. Until then. - JK Laiho -- 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.
