There I think you are going one step too far.
I think people should not be able to override blocks inside an included
template in a "use"-block. That's one level too deep. It's confusing and
you have other solutions for that.
In the template that you "use", you could put a {% block %} around the
From
2011:
https://github.com/vikingco/django-template-tags/blob/master/src/django_template_tags/templatetags/decorate.py
My proposal was refused back then, but I'll be very happy if something
similar would make it. :)
Le mercredi 3 septembre 2014 18:42:44 UTC+2, Jonathan Slenders a
It's not similar. This implements the "decorator" pattern. Something that
I've been proposing years ago.
Le mercredi 3 septembre 2014 18:24:17 UTC+2, Ian a écrit :
>
> On Wed, Sep 3, 2014 at 10:10 AM, Sam Willis > wrote:
> > Although I have implemented this with the 'use' word, there may be a
The "select+1" problem is a problem that people often face in Django.
Usually, something like select_related solves it, but I don't think that's
always possible.
Facebook released Haxl today and there's an example of their apprach to the
problem.
https://github.com/facebook/Haxl/tree/master/exam
Not sure whether this has already been covered. Maybe it is.
I'd like to specify the settings as a class instead of a module. Mostly
because I don't like the "from settings_local import *" pattern to extend
some base settings with machine specific settings. By having the
possibility to define i
For any refactoring of the template engine, going to jinja2, etc... it
would very much help to look at this ticket first:
https://code.djangoproject.com/ticket/20434
It's a backwards compatible patch, which allows template tags to be written
in a much more declarative way, without exposing any
Do we ever intend to implement something like collect_templates in the
future? Similar to collect_static?
If so, implementing this would break collect_templates or the similarity
that we currently have in how app directories are processed.
This is actually the monkey-patching way of writing templ
Le lundi 4 novembre 2013 14:13:44 UTC+1, Emanuele Bertoldi a écrit :
> What about the *add* filter? ;)
>
I forgot about that one.
However, there's probably a reason. It's hard to fix the templating engine
and implement a "+" operator. Because people would expect that whitespace
around the "+"
Rusell's last proposal, using the square brackets sounds the best and
future proof to me. I think it should be something different from the
calling syntax of template tags, because calling of an object or retrieving
a property is not the same.
While I like it, I don't say we should necessarily
Le vendredi 18 octobre 2013 13:27:21 UTC+2, Anssi Kääriäinen a écrit :
>
> On Friday, October 18, 2013 1:31:07 AM UTC+3, Shai Berger wrote:
>>
>> On Thursday 17 October 2013 08:34:48 Aymeric Augustin wrote:
>> >
>> > For instance, thread locals are strictly equivalent to regular
>> variables i
Le jeudi 17 octobre 2013 01:26:20 UTC+2, Russell Keith-Magee a écrit
> What's wrong with thread local storage? Well, try this though experiment.
>
> Everywhere that you see the word "thread local", replace it with "global
> variable". Now re-read your argument.
>
> It doesn't matter how you
The global state problem is something that's been bothering me for a long
while, but after seeing a presentation of Alex Gaynor [1] from last year, I
started thinking about this again.
The main problem is that you'd need to have a DjangoProject object which
contains the root configuration and y
Currently, on python-ideas there is a discussion going on about taint
tracking in Python. It's tracking data that come from untrusted sources and
preventing it from being used in sensitive places. This video [1] from last
year explains the problems very well.
In noticed that we can do better
There's nothing that prevents anyone to track the configuration of the
environment in a VCS.
The guideline that it shouldn't be in the repository of the application
source code is not against that.
Deployment systems should be able to set-up the environment automatically,
(by generating a setti
Would that mean that the object returned by request.DATA/POST/whatever
could be a different type, depending on what the user posted?
I don't want to see code like:
if isinstance(request.DATA, YamlObject): ...
elif isinstance(request.DATA, dict): ...
although, I'm not sure how any view could han
Oh, and denormalisation is not necessarily faster. If you're able to
express the value of the column as an SQL expression, it's possible to put
an index on such an expression.
Le mercredi 17 juillet 2013 13:18:16 UTC+2, Jonathan Slenders a écrit :
>
> This is really nice. Bot
This is really nice. Both have their use cases, but I'm prefering the
second when possible, because it's much more flexible and preserves
database consistency.
With the same efford you can make the following work:
ProductEntry.objects.filter(lambda p: p.onpurchase_price * p.quantity
== 5000.0)
If someone has some spare time. Take a look at this ticket:
https://code.djangoproject.com/ticket/20434
The implementation is finished and consists of 4 patches. See the ticket
for more information. Thanks!
--
You received this message because you are subscribed to the Google Groups
"Django de
We don't even have to change the for-syntax:
{% for bee in my_bonnet.bees %}
{% loop %}
{{ bee }}
{% endloop %}
{% empty %}
No bees!
{% endfor %}
Le mardi 4 juin 2013 00:03:12 UTC+2, Shai Berger a écrit :
>
>
> {% for my_bonnet.bees %}
>
>
By the way, this could also be implemented using just files. The way {%
include %} works for macros. If that's preferred. That becomes:
{% decorate "my_special_for.html" data %}
{{ i.value }}
{% enddecorate %}
Le lundi 3 juin 2013 13:38:29 UTC+2, Jonathan Slenders a écr
Hi all. In the past, I once proposed a decorate template tag, but it was
disapproved back then.
This would be another solution, to make the template language a lot more
powerful.
1. First you define a decorator, for the behaviour you'd like to have. The
"data" parameter indicates the receiving
Update: NEW PROPOSAL.
After extending and refactoring template.Library, and using block_tag as
described above for almost all the built-in tags, I came to the conclusion
that we can improve the template tag definitions even more. I would
introduce some thing as class based template tags.
Actua
Hi all,
For being able to do AST manupulations on templates we need to keep the
grammar of templatetags somewhere.
During the sprints, Russel told me to attach these as a property on the
functions that go into Library.tags. (I would attach an instance of a class
named TemplateTagMeta.)
For tho
Enjoy!
Jonathan
Le lundi 10 décembre 2012 01:07:21 UTC+1, Cal Leeming [Simplicity Media
Ltd] a écrit :
>
>
>
> On Sun, Dec 9, 2012 at 11:40 PM, Jonathan Slenders
>
> > wrote:
>
>> Thanks for your feedback, Cal,
>>
>> You're right about the documentatio
Hi all,
Somebody reported a bug for django-template-preprocessor. I'm wondering
whether this is documented behaviour for the Django template language, or
whether this is just something that happens to be this way because of the
implementation.
https://github.com/citylive/django-template-prepro
Maybe it's worth noting that Guido is working on a Tulip, a specification
for an asynchronous API in Python 3, this to get some consensus. Right now,
there is almost zero compatibility between al the different approaches:
twisted, tornado, gevent, etc...
If we decide to go for one technology, b
As Andrew says, some "rely" on the obscurity of this server side
information. The same can be said of translations. I'd like to see better
support for javascript preprocessing.
gettext(...) in javascript could be preprocessed if the language is known.
url_resolve('name', { ...}) could probably a
Le mardi 5 mars 2013 20:35:07 UTC+1, Michael Manfre a écrit :
>
> Full disclosure, I maintain django-mssql and am biased toward having all
> database backends treated as if they were 3rd party backends.
>
The question is, how monolithic do we want to have Django?
If we would move database back
a simple overview section explaining common uses, what
> makes it better than alternatives, etc.. maybe via readthedocs..?
>
> Statements such as "It's as declarative as possible.." sound impressive,
> but don't really give me much insight into what this is, and wh
Hi Everyone,
In the past there have been some discussionh about how to deploy Django web
applications through SSH. How to use Fabric or other tools, and whether we
should provide or maybe force users to deploy applications according to a
certain conventions.
Back then, maybe already more than
Hi everyone,
This may be interesting to some of you. I created a small library for
inheritance of *a set of* models.
It's best to go quickly through the Readme on the site below.
We felt a need for this, but I'm wondering whether some kind of inheritance
like this has been discussed before. And
On 16 fév, 13:05, Tom Evans wrote:
> 75 isn't large enough these days for either email or username. We run
> a patched version of django for some time that has changed both these
> fields to 255 characters in order to accommodate the needs of our
> users. See RFC 3696.
This and other issues made
On 25 oct, 14:28, Thomas Guettler wrote:
> I would like to see a common variable in django's settings:
> STAGE=...
> with one of this choices: DEV, INTEGRATION, QUAL, PROD
>
> It would be nice, if the django core could agree on a variable name and its
> content.
> Several deploy apps could u
On Oct 24, 2:18 pm, Markus Gattol wrote:
> I agree with others that this is better left to tools such as fabric/cuisine
> as they are build to handle these kind of
> tasks:http://readthedocs.org/docs/fabric/en/latest/api/contrib/project.html
There's indeed no generic way of deploying for every
I agree with Donald's reasoning. Decorators belong to functional
programming, not to OO programming. Though, I still like to keep using
functions for my own views and there are decorators appropriate.
But if you go class based, you better use inheritance. However,
instead of mix-ins, I'd rather pr
On 22 août, 10:02, Aaron Sokoloski wrote:
> Hmm, that's a tricky issue. If it is set in stone that url parameters are
> not unquoted automatically before they hit the view function, that implies
> that reverse should not quote automatically.
Do you mean that when a URL is resolved, the view sti
Hi Jannis,
Thanks for your efford on staticfiles!
I guess the patch is okay, but I didn't review it in detail.
Also a utility function in staticfiles for reading the actual content
on the server side, giving a relative path would be nice if such one
does not yet exist.
e.g.
from staticfiles.ut
This one is a more powerful compressor, but does not easily work out
of the box on every website:
https://github.com/citylive/django-template-preprocessor
I personally think there are too many ways of minifying content.
Minifying is about making assumptions about what information in the
files you
Something related I was wondering about...
Errors in templates should be silenced -- I agree with that -- but
only when they are caused by an error in the template.
Variable.resolve can fail silent because that's caused by the template
author, who is referring to non-existing variables.
However,
I'm also +1 on {% language lang_code %}... {% endlanguage %}
We are using exactly this template tag for maybe about half a year
already. Not for i18n urls, but for formatting numbers. The decimal
separator in Dutch is a comma, but sometimes we want to be sure to
have a dot a some part of the templ
Thanks Roberto,
We had UWSGI 0.9.6.8 installed first. Now I did an upgrade to 0.9.8
and now everything works perfect.
Thanks a lot for the quick response.
On 14 juin, 15:00, Roberto De Ioris wrote:
> Il giorno 14/giu/2011, alle ore 14.54, Jonathan Slenders ha scri
if I replace:
> if type(socket._fileobject) is type and
> isinstance(self.environ['wsgi.input'], socket._fileobject):
by:
> if True
in django.core.handlers.wsgi.py
Then, everything works perfect, so it has to be in this check.
--
You received this message because you are subscribed to the Go
Hi all,
Using WSGI on production environment:
In django.core.handlers.wsgi.py is a clear notice that wsgi.input,
which can be an instance of socket._fileobject will hang when reading
past the available count.
In my case, wsgi.input appears to be of the type 'file', so the
following test fails,
On 9 juin, 10:51, Tom Evans wrote:
> I disagree entirely. The stack trace is the first thing I look at, and
> whilst we need to make it easy for people to learn django, we
> shouldn't be hiding essential information from people - even if it is
> just hidden in a separate 'tab'.
Me too. Why is
Indeed, this is nothing that has to be in the Django core. You can do
something like this:
http://dpaste.com/hold/552209/
Although, I do not think that's the best solution. By catching all
DoesNotExist errors, the Django middleware will not receive the
exception anymore and exception logging fram
> This means that it will not be possible to use block tags inside
> includes. This is not possible now, but there is an open ticket that
> would like to make it possible (only for the special case quoted
> string path includes).
It's certainly possible to use {% include %} inside a template. It's
This is something I have been questioning myself for a while now. Is
the current behaviour of {% trans %} like it should?
We have safe_string, which marks a string as safe for being rendered
in HTML.
{% trans %} blocks appear to be always considered safe. So {% trans
"test" %} will render strong
RT,BLOCK_TAG_END,...}
On 27 mai, 09:07, Michael Blume wrote:
> Would it be possible to customize the markup Django uses for template
> compilation, either at the project level, at compile-time, or embedded in
> the template itself?
>
> -Mike
>
> On Thu, May 26, 2011 at
+1 for the verbatim tag. I think this is something that we need in
Django by default.
But I think that ericflo his implementation is not truly verbatim. I
mean, that it will probably drop whitespace between "{%" and the tag
names. It may not be important for jQuery, but if we implement
verbatim, t
Even more confusing, but extremely great to abuse!
base.html
{% block a %}{% endblock %}
{% block b %}{% endblock %}
{% block c %}{% endblock %}
{% block d %}{% endblock %}
{% block e %}{% endblock %}
index.html
{% block a %}
{% block b %}
{% block c %}
{% blo
Hi all,
This seems like a weirdness in template inheritance...
base.html
{% block title %} ... {% endblock %}
{% block content %}... {% endblock %}
index.html
{% extends "base.html" %}
{% block content %}
{% block title %}
some text
{% endblock %}
{% endblock %}
The paragraph is sh
1. Like Carl said, I always prefer template tags which alter the
context to create a scope. (I hate {% url ... as varname %})
{% form "table" %}
{% renderform my_form %}
{% endform %}
2. Also totally agreed with Russell that we need consistency about
when template tag parameters need to be q
Ticket created.
http://code.djangoproject.com/ticket/16038
--
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-develo
Hi all,
This may be a bug in Django.
We have a lot of forms and datetimefields. Apparently, DateTimeInput
objects are initialized right after the first page load of the server,
where self.format for this instance is set according to the current
language.
DateTimeInput._format_value, which is call
On 18 mar, 13:43, sdcooke wrote:
> I realise this doesn't apply to everyone but we've been coming up
> against
> this recently and every time I've looked at creating a JavaScript
> version of
> the URLs functionality I felt like it was overkill for our needs. 90%
> of our
> situations (again, mig
Russ his solution is better indeed, but the content of the middle
block has to be defined in the child template, so it would become the
following:
a.html
{% block decorated %}first {% block content %}{% endblock %} last{%
endblock %}
b.html
{% extends a.html %}
{% block decorated %}left {{ b
Hey, this pattern are nested decorators in templates.
Most people here are probably against having nested template tags with
the same name. I think it does only make sense when there's somehow a
distinction between a
"placeholder" and "content". Because otherwise, templates don't know
which block
tead
of the ugly {% trans %} within quotes have no more disadvantages.
And while everything is processed, it's rather easy log all the
strings which are to be translated on the way.
Cheers,
Jonathan
On 19 avr, 15:50, Łukasz Rekucki wrote:
> On 19 April 2011 15:35, Jonathan Slenders
A related question.
How should we thread escape characters when the msgid is generated?
Is the escaping backslash assumed to be part of the translation?
And is this behaviour consistent between Babel and the current parser?
gettext("xy\"zzy 3");
In my opinion, we should completely unescape t
Some concerns, even if I don't know much about the subject.
Are you sure that it's always appropriate to strip indentation? Some
companies (like us) use templates for other stuff than HTML. (like
plain text mail.) In this case the indentation is meaningful (not to
the translator, but important for
Like Russ Magee said, Armin has a lot of experience in this field and
even if he didn't yet decided how to implement a compiled engine for
Django templates, I'm sure he will do a good job on this.
But that certainly doesn't mean that you shouldn't try as well (Even
when it's not accepted for GSoC)
Another one:
Instead of:
def has_key(self,key):
for level in xrange(0,len(self._levels)) :
if self._levels[level].has_key(key) :
return True
return False
do:
def has_key(self,key):
return any((key in l) for l in self._levels)
Ony one "s
Hi Andrey
I haven't yet looked through all of your code, but already a little
feedback.
Remember that every dot operator requires a dictionary lookup or
getattr call. Also the [ ]-operator is another level of redirection. I
think using 'self' inside a for-loop is not a good idea. If you're
going
How exactly do you want to solve dynamic inheritance? It seems that
some people are still interested in dynamic inheritance, by using {%
extends variable %}. (Which is still dirty in my opinion, but anyway.)
Block information has to be kept somehow.
Maybe one small improvement. Isn't the followin
> Alex Gaynor wrote:
>
> ... The
> semantics of Python code is that variables assigned in a for loop
> exist beyond the loop itself, including the looping variable. Django
> templates, however, pop the top layer from the context stack at the
> end of a for loop. This intermedia
65 matches
Mail list logo
