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
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,
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
> 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 be
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...@google
.
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
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 :-
(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
l 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.contex
ates
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 f
ugh.
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 Goo
11 matches
Mail list logo
