i'm watching the ticket right now.
maybe there is no need to to create a class
JSONDateEncoder(json.JSONEncoder) because there is DjangoJSONEncoder
already.
then it would be great to implement a lazy translation object for
DjangoJSONEncoder to store ugettext_lazy objects.
for me there is no need t
i'm posting this comment into the ticket.
On 6 Nov, 20:14, Ric wrote:
> i'm watching the ticket right now.
> maybe there is no need to to create a class
> JSONDateEncoder(json.JSONEncoder) because there is DjangoJSONEncoder
> already.
> then it would be great to implement a lazy translation objec
request.url_conf has been added with django 1.3.
in my opinion, the loader object should handle the request, so that
can be sublassed to pass different template folder based on request
params.
i need this feature for my app, is it possible to have different
template folder based on request params
Hi there,
My name's Chris Northwood and I'm a core contributor to the Molly
Project (http://mollyproject.org/), which is a mobile portal framework
built on top of Django. We're an open source project but we currently
think we're doing quite a few things that are "non-core" for us, and
we'd like to
Chris,
Your message comes at a time of frequent discourse over the matter of
apps and pluggability. There's no doubt in my mind that a desire
exists in the django community for this functionality, so I'm
certainly +1 on your creation of a patch. There's no single ticket
around which this matter
for me a simple solution to this is issue, is that django should be
able to recognize an HttpResponse as error and return it
like:
raise HttpResponseRedirect(url)
or
raise HttpResponse(render_to_template("errors/user_not_logged"),
context = RequestContext(context), status_code = 401)
with this a
On Mon, Nov 7, 2011 at 3:59 AM, Justin Holmes wrote:
> Chris,
>
> Your message comes at a time of frequent discourse over the matter of
> apps and pluggability. There's no doubt in my mind that a desire
> exists in the django community for this functionality, so I'm
> certainly +1 on your creatio
The way I am handling this type of thing (and this is getting into
django-users territory), is to either:
- have a middleware that catches exceptions, and if they are a sub-class of
HttpError, then return them,
- have a framework which handles this, often by having the CBV handle it in
it's di
I'm doing just this in several cases: I packaged up a JSONField into a
re-usable
application: https://bitbucket.org/schinckel/django-jsonfield/overview
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web vis
it's a good code.
you wrote:
# TODO: Look for date/time/datetime objects within the structure?
and there is no need, because it's handled by djangojsonencoder
On 7 Nov, 07:06, schinckel wrote:
> I'm doing just this in several cases: I packaged up a JSONField into a
> re-usable
> application:htt
10 matches
Mail list logo
