Re: Proposal: The 'use' template tag, a cross between 'include' and 'extends'.

[Jonathan Slenders]

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 écrit :
>
> 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 <sam.w...@gmail.com> wrote: 
>> > Although I have implemented this with the 'use' word, there may be a 
>> better 
>> > word. I considered 'embed' but thought 'use' was a little cleaner 
>>
>> Since it's so similar to 'include', is there a reason not to just add 
>> the new functionality to the existing tag? 
>>
>

-- 
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/f481b5c8-fb59-46e5-bda5-13436a4bb1ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Solving the select+1 problem.

[Jonathan Slenders]

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/example/sql

I don't know enough Haskel to understand this code, but it could contain 
some very nice ideas that apply to our ORM as well.

Cheers,
Jonathan

-- 
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/f81a5db1-9777-4cd0-98b7-25b0bc44f498%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The unsettings project

[Jonathan Slenders]

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 it in a class, I could use inheritance.

from project.base_settings import BaseSettings
class MySettings(BaseSettings):
INSTALLED_APPS = BaseSettings.INSTALLED_APPS + [...]
...

It's also a solution for "lazy" settings, like said above. Create a 
property in the settings class, etc..
This should easily be backwards compatible.

-- 
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/428b0f36-b4b5-40db-af97-39ebbba01b09%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Switching to Jinja2 proposal

[Jonathan Slenders]

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 internals of the 
parser in the API. If all template tags are eventually rewritten in this 
system, we could deprecate the old way and have a chance to play with the 
parser. (But even if we wouldn't depracate old template tags. It's still 
cleaner.)

This would probably also allow the same template tags of Django to be used 
by Jinja2.

I wrote that patch a year ago, so not sure whether it still merges.




Le dimanche 9 février 2014 23:53:36 UTC+1, Russell Keith-Magee a écrit :
>
>
> Hi Curtis,
>
> If true, this would certainly be a reasonable improvement.
>
> However, I'm not sure it would be a great GSoC project. 
>
> This would have to be posed as a "optimise the template language" project, 
> which is problematic when we don't know for certain ahead of time where the 
> problems lie. We're not likely to accept a 12 week fishing expedition, 
> because there's a possibility that the student will run out of things to 
> fix after 2 weeks.
>
> The only way that this would be an acceptable GSoC project would be to 
> present a pre-analysis that demonstrated that there was 12 weeks worth of 
> things than needed to be optimised. However, my experience with 
> optimisations of this sort has been that *finding* the problem is usually 
> 90% of the work. Once you know *what* is slow, cleaning up a code path or 
> caching a slow lookup is comparatively easy. 
>
> However, if someone wants to look for sources of optimisation outside of 
> GSoC, I'd encourage them to do so.
>
> Yours,
> Russ Magee %-)
>
> On Sun, Feb 9, 2014 at 8:56 AM, Curtis Maloney 
>  > wrote:
>
>> Can I suggest a 3) to this?
>>
>> After getting involved with the internals of the template engine 
>> recently, I came to the suspicion that a lot of the speed issues come from 
>> highly defensive coding.
>>
>> Now, this is generally to be expected when safety is more important than 
>> speed, but I am moderately firm of the opinion that some careful analysis 
>> of the template code could help reveal places where the same guard [such as 
>> mark_safe, force_text, etc] is being applied repeatedly but could be 
>> avoided.
>>
>> So my (3) to this is to analyse the template code paths sufficiently to 
>> be able to identify places where these guards can be omitted safely.
>>
>> --
>> Curtis
>>
>>
>>
>> On 9 February 2014 11:11, Russell Keith-Magee 
>> > > wrote:
>>
>>>
>>> On Sun, Feb 9, 2014 at 6:16 AM, Christopher Medrela 
>>> >> > wrote:
>>>
 Hello! GSoC 2014 is coming and I'm thinking about issue to work on.

 The template system is one of the components that are of special 
 interest to me.
 One of the major issues is that rendering templates is slow. The 
 problem could
 be solved by compiling template to Python bytecode, but it seems to be 
 really
 hard to achieve, given that there was an unsuccessful attempt.

>>>
>>> This should set off a red flag for you. The GSoC project to byte code 
>>> compile Django's templates was implemented by Armin, the same person who 
>>> wrote Jinja2 - and yet the project didn't fully succeed. It's worth 
>>> investigating *why* this idea failed, because it flags one of the reasons 
>>> why "just adopt Jinja2" may not be a viable options.
>>>   
>>>
 Why not switching to Jinja2? I thought that somebody else proposed this 
 idea
 but I couldn't find any discussion; so, please, point me to the 
 discussion if
 the idea was discussed, otherwise let's discuss it!

>>>
>>> It's been proposed in jest, and it's been accepted in jest as well :-) 
>>> However, I don't think there's been a serious proposal to this effect.
>>>   
>>>
 The pros are obvious: 1) fast templates, 2) less code to maintain, 3) 
 lot's of
 companies use Jinja2 (because of slowness of default template system) 
 and
 builtin support for Jinja2 would be beneficial for them (thing about
 integrating Jinja2 with settings like TEMPLATE_DEBUG).

 Now the cons. First of all, one of the design decision is that Django 
 has no
 dependencies. We can overwhelm it by "static linking" -- I mean copying 
 Jinja2
 code into Django. At the first glance, it may look like a horrible 
 idea, but
 think about it in a different way. If we don't switch to Jinja2, we 
 have to
 maintain entire template system and fix every bug as well as implement 
 new
 features. If we switch, Jinja2 developers can do this job for us. We 
 only need
 to forward tickets to Jinja2 developers and update the static linkage.

>>>
>>> We're unlikely to vendor a copy of 

Re: Self-referenced template recursion handling

[Jonathan Slenders]

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 templates.

Probably a weak argument. I'm still against, but practically beats purity.



Le samedi 7 décembre 2013 18:07:18 UTC+1, Florian Apolloner a écrit :
>
> Hi,
>
> there is no need to convince us that this feature would be nice to have; 
> the ticket is accepted… I left a comment on the ticket page; and I think we 
> should do this in one patch instead of two, so we can get the API right 
> (Especially since I am not sure if skipping the loaders is the correct 
> approach).
>
> Cheers,
> Florian
>
> On Saturday, December 7, 2013 1:06:30 PM UTC+1, Goinnn wrote:
>>
>> 2013/12/6 German Larrain 
>>
>>> On Friday, December 6, 2013 11:36:00 AM UTC-3, unai wrote:

 Lot of app/CMS creators create base templates for their apps. 
 Currently, if one 
 of those templates needs some kind of change, the user needs to copy 
 the 
 template all over again, making it difficult to update their templates 
 when 
 they update their apps (they would need to copy the new template and 
 then make 
 their customizations again). 

 Skipping the current template loader means that they would be able to 
 create 
 their own template (with the same path as the app template), extend it 
 to 
 itself and only change the blocks that need to be changed.

>>>
>>>  I would love this feature because I've faced the mentioned problems.
>>>
>>
>> I really like it this feature. I have used this feature from 3 years ago, 
>> through an external app [1], in a lot of projects and never I had any 
>> problem with it. The more relevant project have been the Malaga University 
>> website [2].
>>
>> Without this feature looks like that Django despises the template code, 
>> because If you want to update a little thing of a reusable app 
>> (django.contrib.admin, django-mptt, django-tables2 etc) in your project 
>> (The most common usecase for this feature) you have to overwrite the 
>> complete template [3]. With this feature you will be able to do something 
>> like the before example, you will be able to overwrite only some blocks (or 
>> one block) of a template.
>>
>>
>> REF's
>>
>> 1. 
>> https://pypi.python.org/pypi/django-smart-extends/
>> 2. http://www.uma.es/
>> 3. 
>> http://www.agnostic-library.com/ma/wp-content/uploads/2012/01/Dont-Copy-Paste.png
>>  
>> Best regards,
>>
>> --
>>
>> Pablo Martín
>>
>

-- 
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/d7060744-95c5-464c-a5bd-1a7d38b30432%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Add a generic "getter" filter to the built-in library

[Jonathan Slenders]

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 "+" should be possible. But that destroys almost all the 
template tags now, because we first do token.split_contents in practically 
every template tag, end then do var.resolve() on every part. Actually, 
var.resolve() should receive the whole string. I think it should even 
evaluate the "==" operator, what is done in the {% if %} tag now. (and the 
length_is filter)

It's of course possible to add a "+" operator and allow all the built-in 
tags to use it in var.resolve(), but it will take forever until all 
external template tags have been fixed. People will expect the "+" to work 
in any context.

I had a backwards-compatible patch to make writing template tags easier and 
more consistent. I'd like to work toward such a consistent context free 
grammar. The patches are from half a year ago, so not sure whether it 
merges, but reviews are welcome.
https://code.djangoproject.com/ticket/20434


b.t.w, if we implement the []-operator, we can maybe use that for slicing 
as well, instead of the slice filter that we have right now.

-- 
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/47ed653f-9dbd-46c2-8d44-74c3fef4ac09%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Add a generic "getter" filter to the built-in library

[Jonathan Slenders]

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 allow it, but the square 
brackets allow for nesting. e.g.

{{ object[attribute.name] }}

or even:

{{ object[attributes[something].name] }}


Semantically, the following tree are the same:

{{ object.name }}

{{ object["name"] }}

{% with "name" as var %} {{ object[var] }} {% endwith %}

Another reason for using another syntax for filters and attribute lookups 
is that I think it can be possible in the future to use any arbitrary 
object from the context as a filter.
Say, for instance that from a view, we put a dictionary of filters in the 
context. The following would be possible.

{% my_var|my_filters["escape"]:param %}


As said, we should be careful not to create a complete programming 
language. For me, that means:
- Template tags should never cause side effects. (They should not be able 
to change anything in the database or anywhere else. However, that's hard 
to force!)
- The only operators that we should implement are those necessary for data 
lookups. We shouldn't implement addition or subtraction operators for 
example.
- The template author shouldn't have to care whether the attribute lookup 
happens in a dictionary (through getitem) or in an object (through getattr).
- The template author shouldn't be concerned with how expensive some 
attribute lookups are, for instance when an attribute lookup causes a 
database query. (That's also a hard one, we cannot make all lookups cheap, 
or forbid expensive lookups.)

I think in order to avoid that many projects will create their own template 
filters and template tags as workarounds to syntax limitations, we really 
shouldn't artificially limit the syntax to the most obvious lookups. (I'm 
rather against the idea of custom template tags, but not against filters.)

B.t.w. if anyone has template engine related patches ready, I'm always 
willing to review it.

Cheers,
Jonathan



Le lundi 4 novembre 2013 01:24:45 UTC+1, Russell Keith-Magee a écrit :
>
>
> On Sun, Nov 3, 2013 at 9:57 PM, Emanuele Bertoldi 
>  > wrote:
>
>> I've opened a ticket (#21370) with a proposal for the *inclusion of a 
>> generic "getter" filter* in the built-in library.
>>
>> *Why?*
>>
>> Well, because at the moment Django's template system really lacks of 
>> support for retrieving data from existing context variables in all the 
>> cases in which the name of the attribute we need is determined at execution 
>> time.
>>
>
> It's worth pointing out that this is something the Django core team has 
> historically rejected, on the basis that it's a slippery slope from here to 
> turning Django's template language into a fully featured programming 
> language. So -- fair warning -- the default answer here is going to be 
> "No"; it's going to take some convincing to flip that position.
>
> However, I will admit that this is a use case for which I have some 
> sympathy. Cross-cutting arrays of data is one of those things that is a lot 
> more complex to do in the context than it would be to do using a simple 
> lookup in a template. 
>
> Formally, I'm probably +0.1 :-)
>  
>
>> *Syntax:*
>>
>> {{ object|get:attr_name }}
>>
>> Of course the idea is to add a multi-purpose filter which covers 
>> different use cases (model instances, arbitrary objects, dicts, lists, 
>> tuples, etc.)
>>
>
> *IF* we are to add this, I'd be inclined to do this as a primitive of the 
> template language itself, rather than as a template filter. This is a 
> fundamental concept in context lookup, not a data transformation (which is 
> what filters generally represent). 
>
> The minimal syntactic solution would be to use the colon operator to 
> denote arguments in the same way as it does for filters:
>
>  {{ object:attr_name }}
>
> or, by introducing square brackets as parseable symbols in the template 
> language:
>
>  {{ object[attr_name] }}
>
> The latter has the benefit of being compatible with Jinja syntax; the 
> downside is that Django templates starts to look even more like a 
> programming language.
>
> Yours, 
> Russ Magee %-)
>

-- 
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/7a3368e7-1e89-4433-b390-b0ad7a30ef3c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Possible idea for removing global state in Django.

[Jonathan Slenders]

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 in 
>> > tests because they are single threaded (with a handful of exceptions). 
>> But 
>> > allowing testing in isolation is a major goal of "removing global 
>> state". 
>>
>> If I understand correctly, what Jonathan is suggesting is not your 
>> garden- 
>> variety thread-local variables, but what Common Lisp calls "dynamically 
>> scoped 
>> variables" -- you could call them "call-stack-local" or something like 
>> that. 
>> In Python terms, every change to the values of such variables would be 
>> done in 
>> the __enter__() of a context manager, and undone (that is, old value 
>> restored) 
>> in the __exit__(). I think such variables are a great idea, and would 
>> indeed 
>> help a lot with all the problems associated with global state. In terms 
>> of 
>> software engineering, they are a lot like exceptions: A channel of 
>> communications between functions on different levels of the call stack, 
>> that 
>> does not require explicit acknowledgement on every level, and yet does 
>> not 
>> completely break locality. 
>>
>> However, I don't think such variables can be used in a reliable and 
>> elegant 
>> manner without language-level support, and sadly, Python does not support 
>> them. Attempts I've made to get the functionality using context managers 
>> ended 
>> with awkward APIs for either setting values, getting values, or both; as 
>> a 
>> trivial example, Jonathan's suggestion of the context manager being 
>> returned 
>> by django_project.activate() is of such low granularity, that it is 
>> almost 
>> equivalent to regular globals. 
>>
>> If a reasonable API for this can be defined, I'd be all for it. I suspect 
>> that's a non-trivial "if". 
>>
>
>
> One possible improvement is to start collecting all global and thread 
> local state under one object (call it "env" or something like that). That 
> way it would be a lot easier to actually see what global state you are 
> using. Currently that isn't at all clear. We have a couple of different 
> thread-local storages, and then we have a lot of cached values based on 
> settings, import time actions etc.
>
> The difficulty of doing this will likely be somewhere between really hard 
> and impossible. And that environment object might end up as a God Object 
> for Django (http://en.wikipedia.org/wiki/God_object). So maybe not so 
> great idea in practice...
>
>  - Anssi
>

I'm in favour of everything that makes it easier to see where we still have 
a global state.

About threads, I realised there's the case where you'd use a threadpool in 
a Django views for optimising stuff. The thread locals wouldn't work there, 
so that means we would have to offer an API for copying thread locals from 
one thread to another... Maybe very dirty, but I wonder whether Python has 
a concept of "parent thread" and whether thread locals could look in there?


-- 
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/f0e8883d-884c-4cb6-97d4-6597540a5bfe%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Possible idea for removing global state in Django.

[Jonathan Slenders]

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 gussy it up -- a thread local is a global 
> variable, with all the software engineering consequences that follow from 
> that, including increased coupling, decreased cohesion, complications for 
> testing, and so on.
>
 

 It is a safe convention, I think. Actually every variable on the call 
stack is a thread local, because every thread has its own stack. In python 
it is possible to read variables from another thread (frame inspection), 
but you just don't do that.

A thread local is a persistent global -- I know --, but if you let it 
behave like a call stack, using context managers in Python, then it's not 
that different from a real local variable. the difference is that a 'real' 
local is on the interpreter's stack, while a thread local is in a 
pure-python stack. Both appear local.
The important part is that these stacks should look identical before and 
after execution of every function call, so that you don't have side 
effects. Python's "with"-statement is amazing at handling this.

Yes, it is more implicit than passing objects around, but it is safe. I 
think that it's also the only option we have.

Personally, for the active language, I would make that a stack as well, and 
deprecate language.activate like it is now.

with language.activate('en'):
do_something();

About relying on that we won't have unexpected context switches in the same 
thread. That would be a safe assumption. There is one exception, called 
Gevent. what Gevent does, is patching IO routines and swapping the current 
call stack for another using a C-extension. That's a dangerous practice, 
which is unsafe by design (Also why Guido van Rossem only wants to have an 
explicit 'yield' for coroutinus.) I'm not sure, but if we want to support 
gevent with thread locals, we meight need to hook into gevent and swap our 
pure-python stacks as well.

Hopefully that explains why I think that thread-locals are not that bad as 
they look.



 
 

-- 
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/78f6a3dc-c84c-4998-afa9-c85ae20efa91%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Possible idea for removing global state in Django.

[Jonathan Slenders]

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 you'd have to somehow pass that object 
around everywhere.

Maybe I'm not the first to think about this, but what's wrong with 
thread-local-storage? In Django, we have a huge advantage above nodejs in 
that there's only one active request per thread and that request should 
belong to only one DjangoProject instance. (We don't have unexpected 
contextswitches in the same thread, like in Twisted or Tulip. -- We can 
make that assumption.)

Actually we are already using threadlocals for the current active language 
[2], so I don't see any reason for not using the same approach to keep 
track of the currently active DjangoApplication object.

It's not a really small project, but not impossible huge either. The most 
important parts of the code that need to be changed to use this thread 
local are:

* django.conf.settings:
We don't want to break that API, so the settings object should become a 
proxy that knows the current active project and returns the correct 
settings.

* the reverse() functions (and a few others) from URL patterns.
URL patterns depend on the application.

* Django models:
That's the harder one. MyModel.objects.get() needs to know the settings, in 
order to know what the current database is.


I would propose a python context manager to move from one project to 
another, if you ever have to. Say that you want to query a model from 
another project, you can do this:

other_django_project = DjangoProject.from_settings_file(my_project_settings)
with other_django_project.activate():
MyModel.objects.get()

manage.py should look like this:

if __name__ == '__main__':
django_project = DjangoProject.from_settings_file(my_project_settings)
with django_project.activate():
execute_from_command_line(sys.argv)


And for the flask-lovers which don't like automatic code generation and 
singleton patterns, they can just use the DangoProject constructor:

if __name__ == '__main__':
django_project = DjangoProject(
url_patterns=root_url_patterns,
installed_apps=[ ... ],

)
with django_project.activate():
execute_from_command_line(sys.argv)


For the why of all this, I refer to the presentation of Alex, but the main 
advantages are that it becomes much more easy to integrate Django projects 
in other Python projects and that unit testing becomes easier: you don't 
have a global state.

What do you think? I don't see real backward-compatibility issues that we 
can't solve. Do I forget something?

Cheers,
Jonathan


[1] https://www.youtube.com/watch?v=0FD510Oz2e4
[2] 
https://github.com/django/django/blob/master/django/utils/translation/trans_real.py#L23

-- 
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/7dd166af-f8d6-4838-9a34-480ef5e5581c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

An argument against mark_safe.

[Jonathan Slenders]

 

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 in Django. We already have mark_safe, but 
what does such a SafeText mean? Safe as HTML, javascript, css, SQL or even 
something else? We know it's usually HTML, but that's not always the case.

Some people still have javascript in their templates and they use template 
tags inside their javascript. :(

Some people use the templating engine even for other stuff then generating 
HTML. The point is that we can't assume that "safe" means "safe as HTML". 
We have many languages in the web and HTML is just one of them.

I propose some changes that are backwards compatible for 
django.utils.safestring:
We should rename SafeText to HtmlText. Further we should not expect people 
to call format_html.

Instead of mark_safe, I propose that we call:
HtmlText(' %s ')
Explicitely annotating a string as HTML.

Instead of format_html, I propose that we do:
HtmlText(' %s ') % 'unsafe text'
Like django.utils.SafeText.__add__, we can implement SafeText.__mod__

I think that string interpolation feels more natural. (Or for those who 
prefer .format(), we can add that method to HtmlText.)

It can also be possible to stack escaping filters in the future:
HtmlText('%s') % JavascriptText("function() { echo '%s'; 
}") % 'hello world'
(implementing JavascriptText can be hard, as escaping is different in 
different parts of the code.)

Further, I would deprecate mark_for_escaping and EscapeData. [2] There 
should never be a reason to call this function.

Any suggestions?

[1] http://www.youtube.com/watch?v=WmZvnKYiNlE
[2] mark_for_escaping = lambda s: str(s) # Actually: mark_for_escaping == 
str

-- 
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/8767da03-070b-4819-8d95-a7787cacd258%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Add strutctured settings module to django 1.7?

[Jonathan Slenders]

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 settings_local.py, gunicorn configuration or anything 
else.) 
We use our own system [1], but I guess that puppet or chef have 
configuration files that can be tracked in a VCS as well. 

Personally, I'm also not yet entirely convinced that environment variables 
are always the solution, but I'm convinced that machine specific 
configuration files don't belong in the application's repository.

[1] https://python-deploy-framework.readthedocs.org



Le mercredi 2 octobre 2013 11:16:51 UTC+2, Tom Evans a écrit :
>
>
> Tracking what login keys are assigned to a specific instance of an 
> application is the entire purpose of configuration management. The 
> reason we keep code in VCS is so that we can be assured what is 
> deployed is coherent and consistent, the same is true for 
> configuration, it must be known and verifiable. 
>
> The entire basis of my position is that configuration is essential 
> code which must be tracked and be verifiable with an audit history of 
> changes. If you don't feel that to be the case, you are unlikely to 
> see the benefit in your configuration. 
>
> The second benefit is in consistency. Both approaches take the same 
> overall method, one file contains secrets/host specific configuration 
> for this server, the second contains generic configuration, and the 
> two are combined. With the environment variables way, where is your 
> host specific configuration? It could be in .login, in a gunicorn 
> launch script, in a shell script - anywhere. How is the configuration 
> defined? Are you "setenv foo bar" because this host is Solaris and 
> you're running csh, or is this an "export foo=bar". Perhaps they are 
> in your supervisord configuration. 
>
> Compare to using a python file - you have full power of the python 
> interpreter to do whatever you need. Everything is in one language, 
> the same language as your code. All configuration will apply 
> regardless of how you start the server, whether it is supervisord 
> launching a wsgi process or you running runserver. There is no 
> requirement for this file to belong to the same repository as the 
> code, or even be in a repository. 
>
> There is absolutely nothing that using environment variables as a 
> source of configuration gives you that you cannot do using a python 
> configuration file and it makes your configuration management messy 
> and chaotic. 
>
> Cheers 
>
> Tom 
>

-- 
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/4ebfd3e1-d71a-4df0-a003-5d4b01118ab0%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Support POST of application/json content type

[Jonathan Slenders]

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 handle any random content-type...



Le mercredi 4 septembre 2013 13:57:29 UTC+2, Marc Tamlyn a écrit :
>
> The thing with request.POST is that it's kinda unintuitive when extended 
> to other HTTP methods (e.g. PUT). This is why the old request.raw_post_data 
> was renamed request.body.
>
> request.POST would behave in the expected traditional web way of picking 
> up form encoded POST data, which would also be available in request.DATA as 
> well, but request.DATA is the "new" way of doing it. Personally, I'd 
> lowercase it though, to remove confusion with the PHP $POST $GET $REQUEST 
> which we mimic on the request object. The generally have different use 
> cases anyway - one for complex web things and the other for standard web 
> browsers.
>
> (the above is what tom said...)
>
> Tom - what else do you have in DRF's Request that you would need?
>
>
> On 4 September 2013 12:56, Tom Christie  > wrote:
>
>> > Creating a request.DATA attribute would break compatibility with old 
>> code and seem to me less intuitive.
>>
>> The implementation would ensure `request.POST` would still be populated 
>> for form data.
>>
>> There wouldn't have to be any backwards incompatible changes, and usage 
>> of `request.DATA` (or whatever better name there might be, perhaps simply 
>> `request.data`) would be entirely optional for using with generic request 
>> parsing, instead of form data only.
>>
>>
>> > Where should request.FILE go in that case
>>
>> request.FILES would be populated by form data as normal, and would be 
>> empty on JSON or other submissions.  In order to support multipart parsing 
>> the request parsing API would need to provide for parsers that support file 
>> upload, in a similar way that REST framework currently does.
>>
>> > Would request.POST just be a call to request.DATA?
>>
>> That's an open question, but I'd probably expect it to only return data 
>> if the request contains multipart or url-encoded form data.  (Ie. the 
>> behaviour wouldn't change.)
>>
>> Cheers,
>>
>>   Tom
>>
>> On Wednesday, 4 September 2013 12:33:00 UTC+1, Stefan Berder wrote:
>>>
>>> Tom,
>>> I agree that the middleware solution is not the best and in my mind 
>>> creates fragmentation of the same type of request handling.
>>>
>>> A generic content-type framework would make the request parsing more 
>>> flexible, stronger to change in the future and open the door to any type.
>>>
>>> I'm curious about the choice of request.DATA though, when doing a POST 
>>> request, I expect the data to be in the POST dictionary and nowhere else. 
>>> Creating a request.DATA attribute would break compatibility with old code 
>>> and seem to me less intuitive. Where should request.FILE go in that case? 
>>> Would request.POST just be a call to request.DATA?
>>>
>>> Stefan
>>>
>>> On Wednesday, 4 September 2013 18:13:12 UTC+8, Tom Christie wrote:

 Hi Stefan,

 Sure, I'd be interested in seeing us improve how we deal with JSON 
 requests and responses.

 My preference would be to introduce a request parsing and response 
 rendering API that allows us to support not just JSON, but any media type 
 that has a parser installed for it.  (I've commented on some of this 
 before, 
 here,
  
 although I think I'm warming towards the idea that it's probably about 
 time 
 we started addressing at least some of this in core.)

 Unsurprisingly I'd suggest the same general approach that is used in 
 REST framework - A lazy `request.DATA` attribute (or similar) that when 
 accessed, inspects the media type on the request, and parses the request 
 stream with an appropriate parser if possible.  The installed parsers can 
 be configured globally, or on a per-request basis.  The existing multipart 
 and form-encoded parsing behaviour would no longer be a special case baked 
 directly into the request object, but instead be the default installed 
 parsers.

 Taking this approach makes it trivial to write views that can handle 
 both JSON and form data, and providing a proper parser API makes it easy 
 for developers to package up and share their own parser implementation, 
 such as YAML, XML and MsgPack.  (And, looking forwards, JSON-based media 
 types such as hypermedia types.)

 In REST framework this behaviour is (by necessity) implemented in a 
 Request object that wraps the underlying HttpRequest, but the same basic 
 implementation can be applied to implementing it 

Re: Hybrid Property request

[Jonathan Slenders]

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. 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)
>
> Or if you don't like the lambda keyword, extend the Q object. Something 
> like this:
>
> ProductEntry.objects.filter(Q(onpurchase_price) * Q(quantity) == 5000.0)
>
>
> Denormalisation is fine if you often do the same query. It's certainly 
> easier to implement, but I wouldn't encourage it too much.
>
>
>
> Le mercredi 17 juillet 2013 03:15:52 UTC+2, Alex_Gaynor a écrit :
>>
>> I'm going to suggest that a virtual field and a materialized field are 
>> slightly different concepts, and porblaly have different internals. The 
>> former requires some hooks in the ORM, the latter is really just some nice 
>> wrapping around existing hooks.
>>
>> In any event there's probably some overal with the composite fields GSOC 
>> for the virtual field, when we generalize fields to N>=1, I'm hoping that 
>> makes generlaizing them to N=0 easier.
>>
>> Alex
>>
>>
>> On Wed, Jul 17, 2013 at 11:12 AM, Jacob Kaplan-Moss 
>> <ja...@jacobian.org>wrote:
>>
>>> On Tue, Jul 16, 2013 at 8:04 PM, Russell Keith-Magee <
>>> rus...@keith-magee.com> wrote:
>>>
>>>> So - functionally, what you describe can be done. What's missing is 
>>>> someone to polish the concepts into a patch for inclusion into Django's 
>>>> repository. If this is something that interests you - get hacking! :-)
>>>>
>>>
>>> I'll bet, in fact, that you could do *both* of these things in a 
>>> *single* implementation. A hybrid property (to use your term) with a 
>>> virtual/concrete flag sounds epic. Show me a good patch and I'll help get 
>>> it merged!
>>>
>>> :)
>>>
>>> Jacob
>>>
>>>  -- 
>>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>  
>>>  
>>>
>>
>>
>>
>> -- 
>> "I disapprove of what you say, but I will defend to the death your right 
>> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>> "The people's good is the highest law." -- Cicero
>> GPG Key fingerprint: 125F 5C67 DFE9 4084
>>  
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Hybrid Property request

[Jonathan Slenders]

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)

Or if you don't like the lambda keyword, extend the Q object. Something 
like this:

ProductEntry.objects.filter(Q(onpurchase_price) * Q(quantity) == 5000.0)


Denormalisation is fine if you often do the same query. It's certainly 
easier to implement, but I wouldn't encourage it too much.



Le mercredi 17 juillet 2013 03:15:52 UTC+2, Alex_Gaynor a écrit :
>
> I'm going to suggest that a virtual field and a materialized field are 
> slightly different concepts, and porblaly have different internals. The 
> former requires some hooks in the ORM, the latter is really just some nice 
> wrapping around existing hooks.
>
> In any event there's probably some overal with the composite fields GSOC 
> for the virtual field, when we generalize fields to N>=1, I'm hoping that 
> makes generlaizing them to N=0 easier.
>
> Alex
>
>
> On Wed, Jul 17, 2013 at 11:12 AM, Jacob Kaplan-Moss 
>  > wrote:
>
>> On Tue, Jul 16, 2013 at 8:04 PM, Russell Keith-Magee <
>> rus...@keith-magee.com > wrote:
>>
>>> So - functionally, what you describe can be done. What's missing is 
>>> someone to polish the concepts into a patch for inclusion into Django's 
>>> repository. If this is something that interests you - get hacking! :-)
>>>
>>
>> I'll bet, in fact, that you could do *both* of these things in a *single* 
>> implementation. A hybrid property (to use your term) with a 
>> virtual/concrete flag sounds epic. Show me a good patch and I'll help get 
>> it merged!
>>
>> :)
>>
>> Jacob
>>
>>  -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>
>
> -- 
> "I disapprove of what you say, but I will defend to the death your right 
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>  

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Keep template tags grammar (for simple_tag, assignment_tag and inclusion_tag. Extend with block_tag). Ticket 20434 and 20435.

[Jonathan Slenders]

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 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Not calling things twice in templates

[Jonathan Slenders]

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 %} 
>   
>  {% each bee %} 
>  {{ bee }} 
>  {% endeach %} 
>   
> {% empty %} 
>  No bees! 
> {% endfor %} 
>

 

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Not calling things twice in templates

[Jonathan Slenders]

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 écrit :
>
> 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 parameters.
>
> {% define my_special_for "data" %}
> {% if data %}
> 
> {% for i in data %}
> {% placeholder %}
> {% endfor %}
> 
> {% else %}
> nothing found...
> {% endif %}
> {% enddefine %}
>
>
> This definition can be used as follows:
>
> {% decorate my_special_for data %}
> {{ i.value }}
> {% enddecorate %}
>
>
> Not sure about the namings, but personally, I'm very convinced about this 
> appoach. There shouldn't be too much logic in the template tags itself.
>
> Another nice thing is that the  and  tags happen to be in exact 
> the same scope which increases readability and the posibilities for 
> automatic validation.
>
> An extended version would create a second {% placeholder %} block for the 
> "nothing found..." part.
>
> If this is an acceptable appoach, I'm willing to contribute this to Django 
> core, and write unit-tests and such.
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Not calling things twice in templates

[Jonathan Slenders]

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 parameters.

{% define my_special_for "data" %}
{% if data %}

{% for i in data %}
{% placeholder %}
{% endfor %}

{% else %}
nothing found...
{% endif %}
{% enddefine %}


This definition can be used as follows:

{% decorate my_special_for data %}
{{ i.value }}
{% enddecorate %}


Not sure about the namings, but personally, I'm very convinced about this 
appoach. There shouldn't be too much logic in the template tags itself.

Another nice thing is that the  and  tags happen to be in exact 
the same scope which increases readability and the posibilities for 
automatic validation.

An extended version would create a second {% placeholder %} block for the 
"nothing found..." part.

If this is an acceptable appoach, I'm willing to contribute this to Django 
core, and write unit-tests and such.

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Keep template tags grammar (for simple_tag, assignment_tag and inclusion_tag. Extend with block_tag). Ticket 20434 and 20435.

[Jonathan Slenders]

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.

Actually, all of the template tags return a Node instance after parsing. 
And almost all the template tag that we have, can be expressed as a grammar 
like this: 'if elif* else? endif'. (Exceptions are comment and verbatim, 
which ignore the inner template tags, and trans/blocktrans which have some 
backward compatibility code in there.)

There is no reason for not adding some abstraction level to the parser, as 
long as it's well implemented. The node tree, after parsing will be exactly 
the same. It's just the compile-functions which can be abstracted.

I propose creating a class TemplateTag, which inherits simply from Node. 
Actually, it's a node that was created because the template tag was found 
in the template. TemplateTag.__init__ will receive the parts, like for 
instance:



class IfTemplateTag(TemplateTag):
grammar = 'if elif* else? endif'

def __init__(self, parser, parts):
self.conditions_nodelist = []

for p in parts:
if p.name in ('if', 'elif'):
condition = TemplateIfParser(parser, p.args).parse()   
 self.conditions_nodelist.append( (condition, p.nodelist) )
elif p.name == 'else':
self.conditions_nodelist.append( (None, p.nodelist) )

library.register(IfTemplateTag)

(Probably, I'll make it TemplateTag.parse, instead of __init__, so that we 
can save the nodelists to the class and make the nodelists property 
automatically.)
Register would call IfTemplateTag.create_compile_func(), and add it to 
library.tags, and this compile function will have a pointer to the Grammar 
and TemplateTag class for introspection.
It's powerful. The "with"-template tag, will probably be not much more than 
adding a ContextMixin to the TemplateTag.

If no-one is against, I go on improving and implementing this. I strongly 
believe that there's a lot of room for improvement here, without loosing 
backwards compatibility or performance.

QUESTION: Do we consider the classes IfNode, IfEqualNode, etc... part of 
the public API? They don't appear anywhere in the documentation.
It is because if I implement the new template tag definitions, I'l like to 
refactor all the built-in template tags to use the new style. (As using 
more of Django -- inside Django.)
And this can probably break some monkey-patches on django for those who do 
it.

Cheers,
Jonathan

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Keep template tags grammar (for simple_tag, assignment_tag and inclusion_tag. Extend with block_tag). Ticket 20434 and 20435.

[Jonathan Slenders]

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 those who wonder what the applications are. They are mainly for 
template preprocessing, HTML validation, and code completion in editors, 
when writing Django templates.

For simple_tag, assignment_tag and inclusion tag. The grammar rules are 
easy.
For any other custom tag it's right now impossible to extract the grammar.

The reason is mainly that it is too complicated to define custom template 
tags which consist of an open/close tag.
It should certainly not be necessary to touch the (parser, token) tuple.

I propose that we introduce a new, more user-friendly way of defining these 
tags. I created register.block_tag, but I'm not sure about the API. This 
works, and it's is all we need for the built-in "if" template tag.


@register.block_tag('if elif* else? endif')
def do_if(parser, blocks):
conditions_nodelists = []
for name, bits, nodelist in blocks:
if name in ('if', 'elif'):
condition = TemplateIfParser(parser, bits).parse()
else:
condition = None
conditions_nodelists.append( (condition, nodelist) )

return IfNode(conditions_nodelists)


The advantage is that it's both much more easy to write custom template 
tags which have one or more "bodies", and that this declaration allows us 
to extract the grammar rules of templates. (Which can be used for 
preprocessing, or HTML validation.)

Note that we don't deprecate the old way of writing template tags. It's a 
public API. But we should discourage custom token/parser manupulation in 
custom template tags. 

- What do you think about the name "block_tag"? I'm not sure. 
tag_with_grammar is too long, and the tag function itself cannot be changed 
anymore.
- What do you think about the syntax of the grammar. The space-separated 
notation is more often used in the Python core.
- Is the "parser" parameter really necessary. At least we need it in 
TemplateIfParser. But Why?
- register.block_tag works as well if the templatetags don't have a body. 
In that case, there's only one iteration through blocks, where nodelist is 
an empty list. Would this imply we need another name for "block_tag" or 
not? Otherwise we need something else for -- for instance -- the csrf_token 
template tag.

I'd also like to add a new management command to Django which prints the 
AST for templates. But in a human readable way. I think this would help a 
lot for developers to understand how the template tags of third party 
libraries work. And further, it would make it easier for people to write 
autocompletion plug-ins for a lot of editors.
What do you think would be good as a format, maybe the following?


if elif* else? endif
for empty? endfor
...

...


Further, the following line does not say anything about the template tag 
parameters. 
@register.block_tag('if elif* else? endif')

Should we add some syntax to tell which template tags have or don't have 
any parameters, or leave that to the implementation of block_tag?


Cheers,
Jonathan

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Automatic deployment tool

[Jonathan Slenders]

Hi all,

Some improvements have been made and documentation is coming.

For the curious, here is a 5min screen recording of me using it on our 
deployment environment that I'll present this weekend on djangocon-europe. 
You can watch it here:

https://vimeo.com/66302371


It shows:

- The hierarchical architecture of the deployment tree. (navigation through 
the nodes.)
- Interacting with remote redis shell and the django shell. (some of our 
deployment services.)
- source code introspection
- sandboxing of deployments.
- one complete (sandboxed) setup of our distributed application.

What's not shown, but great:
- typing "--connect" will open a bash shell on the remote end of the 
current node.
- introspection of everything
- a lot more.


Feedback is very welcome, but maybe keep it off django-developers.

https://github.com/jonathanslenders/python-deployer/

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 
> <jonathan...@gmail.com
> > wrote:
>
>> Thanks for your feedback, Cal,
>>
>> You're right about the documentation, some very useful parts aren't even 
>> documented at all. (There are comments in the code, but there are some 
>> little things you wouldn't know from the readme.)
>>
>> During the last years I also put most of the effort in experimenting and 
>> getting something really useful. It took a while before I got there, and it 
>> didn't make sense to document features which were to be refactored every 
>> now and then. However, now I feel its quite stable. I should start making 
>> better documentation, and a lot of usage examples. I also cannot deny that 
>> the learning curve may be a little bit steeper then Fabric in the very 
>> beginning, but soon you will see the advantages. 
>>
>  
>
>> If only I were as good in selling a project as I can code. :)
>>
>
> I know that feeling
>  
>
>>
>> Anyway, I hope this can also improve automatic deployment of Django 
>> applications for other people.
>>
>> Cheers,
>> Jonathan
>>
>>
>> Le lundi 10 décembre 2012 00:15:58 UTC+1, Cal Leeming [Simplicity Media 
>> Ltd] a écrit :
>>>
>>> Hi Jonathan,
>>>
>>> Just from a very brief point of view.. my eyes started to glaze over 
>>> whilst looking at the github README, and even more so when I looked at the 
>>> code.
>>>
>>> Even if this was the best thing since sliced bread, the documentation in 
>>> its current state leaves me with the feeling of "why do I want to use this".
>>>
>>> I think what would benefit this project massively is good/easy to read 
>>> documentation, with 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 why I'd want 
>>> to use it.
>>>
>>>  Hope this helps!
>>>
>>> Cal
>>>
>>> On Sun, Dec 9, 2012 at 3:30 PM, Jonathan Slenders <jonathan...@gmail.com
>>> > wrote:
>>>
>>>> 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 a year ago, I said that I was 
>>>> working on my own deployment tool. [1] Something that could be used 
>>>> instead 
>>>> of Fabric. It's a tool which could probably help a lot of you, although it 
>>>> can take a while to adopt. The core consists of high quality code. I took 
>>>> me a while before I felt confident enough for releasing this, and it has 
>>>> been refactored more then any project I did before. Things still can be 
>>>> improved, but it's ready to share with you.
>>>>
>>>> Key features are:
>>>>
>>>>- Interactive execution of remote commands. Locally, they will 
>>>>appear in a pseudo terminal (created with openpty), so that even 
>>>> editors 
>>>>like Vim or Emacs works fine when you run them on the remote end. You 
>>>> can 
>>>>easy start an interactive shell o

Nested blocks in base template.

[Jonathan Slenders]

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-preprocessor/issues/24


in base:

some html here{% block base %}{% block one %}block 
one{% endblock %}{% endblock %}


In inherited:

{% extends "template_base.html" %}a little bit more html here{% block 
base %}{{ block.super }}and more html{% endblock 
%}{% block one %}overriden block{% endblock %}


The result of Django:

some html hereoverriden blockand more html



Is this documented? If so, then I need to fix it.
(btw, django-template-preprocessor deserves an update as well. It's still 
working nice, but hasn't seen that much progress last year.)


Thanks,
Jonathan

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: websockets

[Jonathan Slenders]

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, better be future proof.

Gevent has some issues. It's doing fine most of the time, but the monkey 
patch approach could really break some stuff.
I like something like Twisted's wsgi container and callfromthread. However, 
I think Twisted it way to hard for the average Django user. It's not really 
intuitive, but hopefully, Tulip will provide us with a nicer API.


Le mardi 16 avril 2013 21:25:08 UTC+2, Jacob Kaplan-Moss a écrit :
>
> Hi Ashwin - 
>
> On Tue, Apr 16, 2013 at 2:10 PM, Ashwin Kumar 
>  
> wrote: 
> > is there any way to implement websockets in django? 
> >  if not, any other packages to combine with django. 
>
> There are quite a few third-party apps and demos out there, so many 
> I've lost track. I recommending searching GitHub. 
>
> >  is there any future plan to implement it in django core? 
>
> I hope so; it was a topic of much discussion at DjangoCon. In the last 
> year, there've been a couple of demos put together by core developers: 
>
> * https://github.com/ptone/django-live 
> * https://github.com/aaugustin/django-c10k-demo/ 
>
> So I think I could sum up the current state as this: 
>
> * Most of us would like to see some sort of real-time support in Django. 
> * There's proof that it's possible technically. 
> * But there's little-to-no consensus on what form this would take, or 
> how to implement it. 
>
> It's probably going to take some time and a great deal of effort to 
> come together on that last point. In the meantime, like I said there 
> are a ton of different apps, demos, and utilities out there, so you 
> should be able to put together a "real-time" app without too many 
> issues. But for something more holistic... it could take a while. 
>
> Jacob 
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: javascript view for named urls

[Jonathan Slenders]

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 also be precomputed, if you're 
smart.

When projects evolve, translation files and url patterns can become large, 
and you don't always want to simply expose all of them.

I'm not sure whether there's already a recommended way for adding compile 
hooks to collectstatic. In debug mode, a fallback to some catalog could be 
a solution.



Le samedi 30 mars 2013 17:24:36 UTC+1, Bernhard Ja a écrit :
>
> Am Freitag, 29. März 2013 21:05:05 UTC+1 schrieb Andrew Ingram:
>
>>
>> I like the concept of this, because it's something I've often wanted 
>> myself. But I want to bring up a couple of points: 
>>
>> 1) Some websites rely on the obscurity of some of their URLs as an 
>> additional security measure (i.e. have the admin at something other than 
>> /admin/). This is admittedly not a great measure, since a persistent 
>> attackers will probably get around it. But the key would be a way to manage 
>> which patterns get included in the javascript catalog, possibly even having 
>> it configurable at the the view level so that some templates can request a 
>> different subset of the patterns to others. 
>>
>
> I agree. A way to manage the existenz in the js catalog is necessary.
>  
>
>> 2) It'd be nice if it could be integrated with internationalisation, so 
>> that if you're using Django's i18n_patterns, the view automatically fills 
>> in the country segment based on the request's locale. Much like the 
>> translation string view only returns the strings for the request's 
>> language. 
>>
>
>  I did some tests and the language code prefix appears in the generated 
> urls. Am i missing sth.?
>
> Whats the best was to propose this feature for the django core? 
>
> Bye, Boerni
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[Jonathan Slenders]

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 backends out of core. Why not move everything in 
django.db away from core? There are other ORMs for Django. And the same is 
true for the templating system.

For me, personally, it's really a big +1 for splitting Django up in several 
logical parts, and for removing the global state. (So that we could create 
a Django *instance*, and add a postgres *instance* to django ourself.)

I want to to see something like this:

d = Django(
database_backend=Postgres(postgres_settings),
urls=our_url_patters,
templates=TemplateSystem(template_settings),
midldeware=...,
   )

No disadvantages I think. But it's not an easy migration path.

Cheers,
Jonathan

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Automatic deployment tool

[Jonathan Slenders]

Thanks for your feedback, Cal,

You're right about the documentation, some very useful parts aren't even 
documented at all. (There are comments in the code, but there are some 
little things you wouldn't know from the readme.)

During the last years I also put most of the effort in experimenting and 
getting something really useful. It took a while before I got there, and it 
didn't make sense to document features which were to be refactored every 
now and then. However, now I feel its quite stable. I should start making 
better documentation, and a lot of usage examples. I also cannot deny that 
the learning curve may be a little bit steeper then Fabric in the very 
beginning, but soon you will see the advantages. If only I were as good in 
selling a project as I can code. :)

Anyway, I hope this can also improve automatic deployment of Django 
applications for other people.

Cheers,
Jonathan


Le lundi 10 décembre 2012 00:15:58 UTC+1, Cal Leeming [Simplicity Media 
Ltd] a écrit :
>
> Hi Jonathan,
>
> Just from a very brief point of view.. my eyes started to glaze over 
> whilst looking at the github README, and even more so when I looked at the 
> code.
>
> Even if this was the best thing since sliced bread, the documentation in 
> its current state leaves me with the feeling of "why do I want to use this".
>
> I think what would benefit this project massively is good/easy to read 
> documentation, with 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 why I'd want 
> to use it.
>
> Hope this helps!
>
> Cal
>
> On Sun, Dec 9, 2012 at 3:30 PM, Jonathan Slenders 
> <jonathan...@gmail.com
> > wrote:
>
>> 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 a year ago, I said that I was working 
>> on my own deployment tool. [1] Something that could be used instead of 
>> Fabric. It's a tool which could probably help a lot of you, although it can 
>> take a while to adopt. The core consists of high quality code. I took me a 
>> while before I felt confident enough for releasing this, and it has been 
>> refactored more then any project I did before. Things still can be 
>> improved, but it's ready to share with you.
>>
>> Key features are:
>>
>>- Interactive execution of remote commands. Locally, they will appear 
>>in a pseudo terminal (created with openpty), so that even editors like 
>> Vim 
>>or Emacs works fine when you run them on the remote end. You can easy 
>> start 
>>an interactive shell on any host as well. 
>>- Reusability of all deployment code is a key point. It's as 
>>declarative as possible, but without loosing Python's power to express 
>>everything as dynamic as you'd like to. Deployment code is hierarchically 
>>structured, with inheritance where possible. 
>>- Parallel execution is easy when enabled, while keeping interaction 
>>with these remote processes possible through pseudoterminals. Every 
>>parallel task gets his own terminal, either a new xterm or gnome-terminal 
>>window, a tmux pane, or whatever you'd like to. 
>>- Logging of your deployments. New loggers are easily pluggable into 
>>the system.
>>
>>
>> So, enjoy!
>>
>> So, what does it have to do with Django? I have a setup-definition of 
>> what we use for Django deployment [2]. However, I suppose that quite a lot 
>> of people aren't using uwsgi like us. So, I'd like to know what the most 
>> common use cases of Django deployment are. If I can cover most cases, it's 
>> very easy for end-users to pick one, override what they don't like, and 
>> enjoy the full power of this deployment system.
>>
>> For instance, to demonstrate the power. If we want to connect to a Django 
>> shell_plus of our Mobile Vikings production system, we type in the 
>> interactive shell:
>>
>> > mobile_vikings django shell_plus
>>
>> This will call the shell_plus function of our django setup, it will ask 
>> on which host the shell needs to be started, and immediately fire an 
>> interactive shell_plus of the remote server in your terminal.
>>
>> [1] https://github.com/jonathan

Automatic deployment tool

[Jonathan Slenders]

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 a year ago, I said that I was working on 
my own deployment tool. [1] Something that could be used instead of Fabric. 
It's a tool which could probably help a lot of you, although it can take a 
while to adopt. The core consists of high quality code. I took me a while 
before I felt confident enough for releasing this, and it has been 
refactored more then any project I did before. Things still can be 
improved, but it's ready to share with you.

Key features are:

   - Interactive execution of remote commands. Locally, they will appear in 
   a pseudo terminal (created with openpty), so that even editors like Vim or 
   Emacs works fine when you run them on the remote end. You can easy start an 
   interactive shell on any host as well.
   - Reusability of all deployment code is a key point. It's as declarative 
   as possible, but without loosing Python's power to express everything as 
   dynamic as you'd like to. Deployment code is hierarchically structured, 
   with inheritance where possible.
   - Parallel execution is easy when enabled, while keeping interaction 
   with these remote processes possible through pseudoterminals. Every 
   parallel task gets his own terminal, either a new xterm or gnome-terminal 
   window, a tmux pane, or whatever you'd like to.
   - Logging of your deployments. New loggers are easily pluggable into the 
   system.


So, enjoy!

So, what does it have to do with Django? I have a setup-definition of what 
we use for Django deployment [2]. However, I suppose that quite a lot of 
people aren't using uwsgi like us. So, I'd like to know what the most 
common use cases of Django deployment are. If I can cover most cases, it's 
very easy for end-users to pick one, override what they don't like, and 
enjoy the full power of this deployment system.

For instance, to demonstrate the power. If we want to connect to a Django 
shell_plus of our Mobile Vikings production system, we type in the 
interactive shell:

> mobile_vikings django shell_plus

This will call the shell_plus function of our django setup, it will ask on 
which host the shell needs to be started, and immediately fire an 
interactive shell_plus of the remote server in your terminal.

[1] https://github.com/jonathanslenders/python-deployer
[2] 
https://github.com/citylive/citylive-operations/blob/master/deployment/deployer/contrib/services/django.py

I'll publish one of these days on pypi.

All feedback is welcome. For bugs/feature requests on things which arn't 
Django related, please go to the github.

Cheers,
Jonathan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/k4RS_9Kmn9cJ.
To post to this group, send email to django-developers@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.

Model inheritance extended.

[Jonathan Slenders]

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 whether, if useful, this would 
make a candidate for django.db.

https://github.com/citylive/django-model-blueprint

Cheers,
Jonathan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/WIkRQuzDRCsJ.
To post to this group, send email to django-developers@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: auth.User usernames

[Jonathan Slenders]

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 us moving away from contrib.auth and
contrib.sessions. It's not too hard to write your own custom
authentication and session middleware, and you can migrate whereever
you want to. The main problem is if you depend on other libraries with
rely on the existance of auth.models.User, like contrib.admin.

Personally, I think a lot of the apps in django.contrib have a lack of
flexibility. Maybe it's good to leave these apps as they are, but
start something like contrib_v2, as the improved version.

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: common variable (Deploying Feature in manage.py)

[Jonathan Slenders]

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 use this common variable.
>
> In our company we have a common variable. PROD is zero:
>
> if STAGE:
>     # some dev system...

Me too. We use CONFIG_DEV='dev', CONFIG_PROD='prod',
CONFIG_BETA='beta' and then assign one of these three to
settings.CONFIG. Our deployment app used to replace CONFIG=CONFIG_DEV
by CONFIG=CONFIG_PROD

It would be good to agree on a naming convension for this.

However,... on newer applications, our deployment app does automatic
generation the parts from the settings (like IP addresses) which are
in production different from the development settings.

The question is, should a git/gh/... repository contain any production
specific settings? (Assuming one is using a vcs checkout.) Deployment
scripts are perfectly capable of replacing the config with production
settings right after the checkout.

Further, I think that applications should be agnostic about in what
environment they run. They should never behave different locally, in
stage or in production. You have settings which contains IP addresses,
DEBUG=True/False, etc... but I think they don't have to know whether
they run in production or not. The only reason for such a variable to
exists, may be to decide between several other settings to include.
Correct me if you think differently.

Cheers,
Jonathan

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Deploying Feature in manage.py

[Jonathan Slenders]

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 everyone...

I'm currently finishing a new deployment framework at my company
(Mobile Vikings), inspired by fabric and also based upon Paramiko (the
SSH) library. (It is not to reinvent Fabric, but we just needed our
deployments to be  more flexibility/powerful. That is as declarative
as possible, readable, DRY and having reusable components, taking care
of cross-server dependencies/references, undo where possible, having a
deployment shell with autocomplete, easy beta/staging duplication, and
more...) If everything goes well and I'm confident, we will place the
stable source code on github and I'll post a link in django-users --
hopefully somewhere within the following two weeks.

By the way, any input of what you think a deployment tool should have,
or what you think that other tools lack is welcome. (send me in PM)

Cheers,
Jonathan

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: RFC: "universal" view decorators

[Jonathan Slenders]

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 prefer a more declarative approach,
like this:

class ProtectedView(MyView):
login_required = True

Where 'MyView' checks all the view's options during a dispatch. Never
liked inheritance with multiple base classes...

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Advice on #13260 - '%' in args to urlresolvers.reverse()

[Jonathan Slenders]

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 still gets quoted
args/kwargs at the moment?
If so, it feels to me we should change that. It does not really make
much sense to retain the escape characters in a view's parameters.

The use of quote/unquote should be consistent everywere. No matter
whether these functions really change anything in the specific case
where it's used. If reverse does not quote anything, you should always
quote it yourself, like here:
>> "http://; + urllib.quote(reverse(...)) + "?param=value"
Even if reverse did not output any special character like '?' or '%'.
If wrapping reverse into quote is required in some cases, we should do
it everywhere before outputting the url into HTML.  Not being
consistent in escaping is how injection vulnerabilities happen...

I think in Django, that one should consider the result of "reverse" as
a final url path. Without query string and protocol off course. But
still not something where you should do any string operation (like
substitution) upon, before passing it to quote.

Someone could do the following, which would not work if reverse did
automatically quoting, but I consider this bad design.
>> reverse('my_page', args=['some-%i-url-slug']) % some_integer
Or this, which is a concatenation of a quoted and unquoted string.
(Which sounds like bad design to me but can be overcome by wrapping
the prefix in quote manually.)
>> "/prefix" + reverse('my_page')

We should also make a decision about whether the regex in the
urlpatterns are written quoted or unquoted.
I would say, keep these unquoted for readability.
>> url(r'^some-%-url/$', ...)

If we have the following patterns:
>> url(r'^(?Psome-%-url)/$', ...)
It should call the view with **{'param': 'some-%-url' }

Like Aaron, I can also see no reason for not quoting the reverse call.

Cheers,
Jonathan

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: RFC: staticfiles "static" template tag and CachedStaticFilesStorage

[Jonathan Slenders]

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.utils import staticfile_open
filepointer = staticfile_open('my-relative-path...')


Thanks,
Jonathan



On 8 août, 12:17, Jannis Leidel  wrote:
> Hi all,
>
> I believe I'm getting close to a fix for #15252 which would add
> a bunch of new features to the staticfiles contrib app. I'd
> appreciated it if someone would review the latest patch at
>
>    https://code.djangoproject.com/ticket/15252
>
> ``static`` template tag
> ---
>
> The purpose of the template tag is to make it easier to refer
> to static files from templates while extending the possibilities
> at the same time. So instead of relying on a context variable
> named ``STATIC_URL`` you could alternatively use the new template
> tag with a relative path of a file you want the URL for, e.g.:
>
>     {% static "css/base.css" %}
>
> Behind the scenes it uses the configured storage backend that
> staticfiles uses when you run collectstatic (STATICFILES_STORAGE),
> which means it's also works with non-local storage backends,
> such as one that deploys to a private Amazon S3 bucket which
> requires using signed URLs to access a file.
>
> In other words, it allows a much richer API to building the URL
> of a static file by using the storage API that is already in place.
>
> CachedStaticFilesStorage
> 
>
> The second feature is an optional storage backend which hooks
> right into the new template tag and is a subclass of the default
> StaticFilesStorage (which is a subclass of FileSystemStorage).
> It basically adds "cache-busting" abilities to staticfiles.
>
> Specifically, when enabled and you run collectstatic it saves
> a second version of each file it finds, only with a MD5 hash
> appended to the filename, which is generated with its own content.
> So if a ``css/base.css`` would be collected, it would also deploy
> a ``css/base.27e20196a850.css``. Any CSS @import and url()
> statements are automatically replaced with the cached path in
> those cached files, too.
>
> Later, when the ``static`` template tag tries to create the URL
> for ``css/base.css``, it will use the same code path to return the
> URL to the cached file instead. To lower the burden of calculating
> the MD5 hash, the result is cached in an own cache backend named
> "staticfiles" (falls back to "default" if not specified in CACHES).
>
> I've written this functionality as a mixin (CachedFilesMixin), so it
> should be possible to use it with any storage backend that supports
> the common API (url(), open() and save()).
>
> I'd appreciate if you would test-drive the feature and let me know
> if you find any big issues since I plan to merge this very soon.
>
> Thanks!
>
> Jannis

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: minify static files (css and js)

[Jonathan Slenders]

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 serve can be removed. If you're going to the extreme -- like
minifying classnames of html elements, and replacing the matching
class names in css and javascript files -- you also have to make other
assumptions about how everything is structured.

We shouldn't have this in Django Core or contrib. Any minification
algorithm can easily be implemented with template loaders, middleware
or template filters.



On 7 août, 16:03, Aymeric Augustin
 wrote:
> Hello,
>
> You're probably looking for:https://github.com/jezdez/django_compressor
>
> Best regards,
>
> --
> Aymeric Augustin.
>
> On 7 août 2011, at 14:36, gert wrote:
>
>
>
>
>
>
>
> > Hi
>
> > I have always wanted to minify my css and js but it never seemed like
> > the right time to do it. Somehow there is always something I know I
> > want to tweak first so I'll release it as is for now... :)
>
> > Having used the django-staticfiles app for some time now I just
> > realised that that would actually be the perfect place to implement
> > minify functionality. I think it will make minification a standard for
> > many sites if css and js files got minified when you run
> > collectstatic.
>
> > Not sure what the implications would be just sharing a thought.
>
> > Regards
> > Gert
>
> > --
> > 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-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/django-developers?hl=en.

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Consistent exception handling in templates.

[Jonathan Slenders]

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, sometimes, it happens to me that the template calls a
@property of some object, which acesses at his turn an non existing
attribute of another object. An AttributeError is raised, but because
that's somewhere in Variable.resolve, it's silently ignored. It's
clear that at that point, it's not something in the template, but a
hard-to-find bug in the @property.

My feeling is that we should silence TypeError, AttributeError and
KeyError in _resolve_lookup, but only when they occur one frame deep.

Maybe I am wrong here, it's also just an opinion, and I have no real
solution... (Except for writing better unit-tests for the application
logic.)

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Reversing translated urls in templates

[Jonathan Slenders]

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 template. (When rendering SVG, JSON or
other markup lanugages.)

So, this is certainly a very versatile approach.

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: WSGIRequest._stream.read() blocking

[Jonathan Slenders]

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 <robe...@unbit.it> wrote:
> Il giorno 14/giu/2011, alle ore 14.54, Jonathan Slenders ha scritto:
>
>
>
>
>
>
>
>
>
> > 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, and the input is not wrapped in a LimitedStream.
>
> > ---
> > wsgi.input.__class__
> > 
>
> > wsgi.input.__class__.__name__
> > file
>
> > wsgi.input
> > 
>
> > socket._fileobject
> > 
>
> > type(socket._fileobject)
> > 
>
> > isinstance(self.environ['wsgi.input'], socket._fileobject)
> > False
>
> > ---
>
> > When I want to read request.raw_post_data, everything hangs.
>
> > It may be worth noting that the CONTENT_LENGTH was zero. (It is sentry
> > in my case who wants to log another error, tries to access
> > raw_post_data, and blocks instead of returning a proper 500 error
> > page.)
> > This is probably a bug in Django, but I'm not sure where exactly.
>
> Even if the read() and read(-1) are controversial, the popular consensus is 
> on having the WSGI server to
> gracefully manages it.
>
> uWSGI 0.9.8 uses the same approach of mod_wsgi (it creates a custom object 
> for wsgi.input), so you are using a old uWSGI version
> or i did not understand your question :)
>
>
>
> > By the way, it would also be great if anybody knows how to use pdb
> > statements, while running uwsgi on the console.
>
> Look here,http://lists.unbit.it/pipermail/uwsgi/2011-April/001769.html
>
> the same is valid for pratically all of the other WSGI daemons out there.
>
> --
> Roberto De Iorishttp://unbit.it

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: WSGIRequest._stream.read() blocking

[Jonathan Slenders]

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 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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

WSGIRequest._stream.read() blocking

[Jonathan Slenders]

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, and the input is not wrapped in a LimitedStream.

---
wsgi.input.__class__


wsgi.input.__class__.__name__
file

wsgi.input


socket._fileobject


type(socket._fileobject)


isinstance(self.environ['wsgi.input'], socket._fileobject)
False

---

When I want to read request.raw_post_data, everything hangs.

It may be worth noting that the CONTENT_LENGTH was zero. (It is sentry
in my case who wants to log another error, tries to access
raw_post_data, and blocks instead of returning a proper 500 error
page.)
This is probably a bug in Django, but I'm not sure where exactly.

By the way, it would also be great if anybody knows how to use pdb
statements, while running uwsgi on the console.

Thanks!
Jonathan

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: get_object_or_404 hook

[Jonathan Slenders]

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 frameworks will not work.
Also, you won't receive an error mail. A better solution may be to
handle this errors in custom middleware, but that's actually to be
discussed at django-users.

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Vote on {% include %} behaviour.

[Jonathan Slenders]

> 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
for the following case, which I often do:

> A includes B; B extends from C.

I really never want to have the {% block %} names of B/C in previous
example to be available for overriding in templates which inherit from
A. This would even cause unexpected collisions between block names.
The author of the include B, is not supposed to know where his
template will be included, and we can't expect him to choose block
names which don't collide with those of A.


I can understand you want to override some part of the include B in
the main template A, that's what I made {% decorate %} for. (Which I
still would like to become a django core tag.) It's different from {%
include %}.

https://github.com/citylive/django-template-tags/blob/master/src/django_template_tags/templatetags/decorate.py


Further, I'm not aware of any inconsistencies in include behaviour
when using variable template names. Maybe anyone else?

Cheers,
Jonathan



-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

{% trans %} and safestring.

[Jonathan Slenders]

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 text. No escaping is
done.
In this case, it's clear for the translator that he should escape
special characters as HTML, because the text is rendered in a HTML
context.

If it were {% trans "Hello" %}, then the translator can hardly
distinguis between that and ` ugettext("Hello") ` in a Python file.
The first seems to be concidered safe, but the second isn't. So, if
you would pass a context { 'hello': ugettext('Hello') } to the
template and render {{hello}}, it will be escaped.

What if the translation would involve inserting special entities which
are not valid in that context? The translator cannot know that he has
to escape it, because he doesn't know where the text is rendered.

In the past, we have used a patch on gettext, which allowed us to add
meta-information to each translation when we felt the need. Like:
_("comment[[ verb ]]"), _("comment[[ noun ]]"), or _("something...
[[ in html context]]") where the gettext patch always removed the meta
information from the ouput, while it was still present in the PO-files
for the translator.

Any thoughts about this? I'm also curious how other people handle
this, and whether other template languages have similar problems.


-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: jQuery.tmpl() and Django

[Jonathan Slenders]

At project level is impossible, because you don't know for sure which
templates belong to which project. But it should be possible to define
the markup syntax for a directory of templates.

Embedded in the template is tricky, that's a chicken and egg problem.
The language should be known, before we are able to parse this kind of
meta information. We can also of course assume that we have the
current syntax at the beginning, and have a template_tag like the
following, which alters the lexer at that point.

{% template_syntax "[%" "]%" %}

But while it is possible and has it's uses, I'm really sure that there
are enough people against a dynamic syntax. It is too easy for the end-
users to screw this up, and abuse it...
I think a verbatim/raw/cdata -like tag is sufficient.


By the way, the syntax is defined in:  django.template.base.
{BLOCK_TAG_START,BLOCK_TAG_END,...}


On 27 mai, 09:07, Michael Blume <blume.m...@gmail.com> 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 11:59 PM, Jonathan Slenders <
>
>
>
>
>
>
>
> jonathan.slend...@gmail.com> wrote:
> > +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, the output should be an exact copy of the verbatim contents.
>
> > Further, because it is possible that other languages use the same {%
> > verbatim %} syntax, we should be able to configure what the end-tag
> > looks like. That way, we can nest {% verbatim %} tags.
>
> > For instance:
> > {% verbatim "===" %}
> >      ...
> > {% "===" %}
>
> > Cheers,
> > Jonathan
>
> > On 27 mai, 07:04, Sean O'Connor <s...@seanoc.com> wrote:
> > > I think it would be a bit much for us to ask the jQuery crew to change
> > their template language to avoid conflict with ours. Aside from the amount
> > of backwards incompatible work we'd be asking them to do, they'd probably
> > just end up with a new conflict with some other template language. At the
> > end of the day this is also more of a symptom than an underlying problem.
> > Even if we got the jQuery crew to change their syntax, there would still be
> > other JS template languages with the same conflict (e.g. mustache.js).
>
> > > A better approach would for Django to provide some tools and
> > documentation to help people work around the conflict. One easy solution
> > would be to provide a verbatim tag like what ericflo wrote athttps://
> > gist.github.com/629508. Another would be to provide documentation on tools
> > that make it easy to load jquery style templates via ajax like icanhaz.js.
>
> > > My vote is that we fix the problem once and for all on our end by
> > providing compatibility tools and guidance instead of trying to tell the
> > entire JS community to not conflict with out template syntax :)
>
> > > --
> > > Sean O'Connorhttp://www.seanoc.com
>
> > > On Thursday, May 26, 2011 at 11:14 PM, Ori Livneh wrote:
> > > > Hello,
>
> > > > jQuery.tmpl(), a beta feature slated for inclusion in the main jQuery
> > > > brach, uses some of the same syntax as Django in its templating
> > > > markup, which is a bit of a bummer. I'm writing to see whether you
> > > > think we should get in touch with the jQuery team to see if they could
> > > > plausibly change it.
>
> > > > There are, obviously, quite a lot of templating languages out there,
> > > > and some of them are bound to clash with Django, and that's not a
> > > > problem. But Django and jQuery are often deployed together (jQuery is
> > > > actually bundled with Django for use in the admin), making this clash
> > > > especially annoying.
>
> > > > You might think this isn't an issue since JavaScript code should be
> > > > served from static files anyway, but there's an added complication.
> > > > One of the patterns jQuery.tmpl() recommends is nesting templates
> > > > within a 

Re: jQuery.tmpl() and Django

[Jonathan Slenders]

+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, the output should be an exact copy of the verbatim contents.

Further, because it is possible that other languages use the same {%
verbatim %} syntax, we should be able to configure what the end-tag
looks like. That way, we can nest {% verbatim %} tags.

For instance:
{% verbatim "===" %}
  ...
{% "===" %}

Cheers,
Jonathan


On 27 mai, 07:04, Sean O'Connor  wrote:
> I think it would be a bit much for us to ask the jQuery crew to change their 
> template language to avoid conflict with ours. Aside from the amount of 
> backwards incompatible work we'd be asking them to do, they'd probably just 
> end up with a new conflict with some other template language. At the end of 
> the day this is also more of a symptom than an underlying problem. Even if we 
> got the jQuery crew to change their syntax, there would still be other JS 
> template languages with the same conflict (e.g. mustache.js).
>
> A better approach would for Django to provide some tools and documentation to 
> help people work around the conflict. One easy solution would be to provide a 
> verbatim tag like what ericflo wrote athttps://gist.github.com/629508. 
> Another would be to provide documentation on tools that make it easy to load 
> jquery style templates via ajax like icanhaz.js.
>
> My vote is that we fix the problem once and for all on our end by providing 
> compatibility tools and guidance instead of trying to tell the entire JS 
> community to not conflict with out template syntax :)
>
> --
> Sean O'Connorhttp://www.seanoc.com
>
>
>
>
>
>
>
> On Thursday, May 26, 2011 at 11:14 PM, Ori Livneh wrote:
> > Hello,
>
> > jQuery.tmpl(), a beta feature slated for inclusion in the main jQuery
> > brach, uses some of the same syntax as Django in its templating
> > markup, which is a bit of a bummer. I'm writing to see whether you
> > think we should get in touch with the jQuery team to see if they could
> > plausibly change it.
>
> > There are, obviously, quite a lot of templating languages out there,
> > and some of them are bound to clash with Django, and that's not a
> > problem. But Django and jQuery are often deployed together (jQuery is
> > actually bundled with Django for use in the admin), making this clash
> > especially annoying.
>
> > You might think this isn't an issue since JavaScript code should be
> > served from static files anyway, but there's an added complication.
> > One of the patterns jQuery.tmpl() recommends is nesting templates
> > within a 

Re: Template inheritance and duplicated content.

[Jonathan Slenders]

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 %}
{% block d %}
{% block e %}
duplicate
{% endblock %}
{% endblock %}
{% endblock %}
{% endblock %}
{% endblock %}


This will print "duplicate", 5 times, and cover cases that a for-loop
can't because all the different blocks in base.html can be spread over
the whole template, whereever you want. :)

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Template inheritance and duplicated content.

[Jonathan Slenders]

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 shown twice in the output. Once, because the block
'title' is copied into the 'title' of the parent during the
inheritance, and once because the block 'content' is copied.

I guess this is a flaw in the inheritance algorithm, only the most
outer blocks should be used during the resolving of inheritance.

Because: if we would extend index.html, and override the block
"title", the current template engine will replace the title-block from
base.html, instead of the nested title-block of index.html which is
completely counter-intuitive.

Is this behaviour documented or on purpuse? We should have a clear
definition of how inheritance should work, especially now the Jinja-
guy is working on a compatible template engine. (And also the template
preprocessor does resolve inheritance at compile time.)

It is otherwise possible that people will start using this flaw as a
kind of macro-feature, to intentionally duplicate content.

Jonathan


-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: RFC: Templatetag API for form rendering

[Jonathan Slenders]

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 quoted.
That is, quoted in case of constants, and unquoted when they need to
be resolved.


And even if this seems to cover all the use cases, ensure
extensibility.

Other than that, nice proposal.

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Bug in DateTimeInput: localization formatting decided during start-up?

[Jonathan Slenders]

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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Bug in DateTimeInput: localization formatting decided during start-up?

[Jonathan Slenders]

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 called during rendering, will
see self.is_localized to be False, and render the data using the
language which happened to be used during the startup of the
application.

is_localized is passed from DateTimeField to Field to DateTimeInput.

For ModelForms, it's no option to pass localize=True for every input
element, and Field will always fallback to localize=False

In combination with localeurl, this bug causes unexpected behaviour,
all datetimefields will render dates according to the language of the
first request after the server has been started.


Feedback about how to work fix or work around this issue is welcome :)

Cheers,
Jonathan

I propose that Field.__init__ should have localize=None, and if no
localize parameter has been given, set self.localize according to
USE_L10N in the settings.

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django urls in JavaScript

[Jonathan Slenders]

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, might not apply to all!) could be solved by
> attaching a
> "data-" attribute to an HTML element. For example, if you're popping
> up an
> AJAX dialog box you could include the url on a button like this:
>
> 
>
> That way, you don't need to do any resolving in JS. Just thought I'd
> mention
> it here in case people come across this thread and unnecessarily start
> adding resolver apps that they don't need.

Weird, I have missed this thread. But anyway, like sdcooke, that's
also the way that we handle URLs in javascript.
Attach a data attribute to the HTML node to which it applies, and read
it from inside the javascript. It's clean.

 {% trans "Edit" %}

Like gettext, a seperate, dynamically generated javascript file for
URL resolving is not scalable to lange web applications.
And further, I think that the urls and names of views are not meant to
be exposed to the client. I don't want a visitor to be able to reverse
engineer my website, and read all the possible URL patterns.

Jonathan


-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Suggestion for improvement to template block/extends tags

[Jonathan Slenders]

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 {{ block.super }} right{% endblock %}

template.html
{% extends (either "base.a.html" or "base_b.html") %}
{% block content %}middle{% endblock %}



Off topic:
The {% decorate %} template tag has its uses, but is indeed not
required here.
It is a design pattern that's commonly used in languages like
XAML.net.
It is more readable and compact than the only current alternative:
including a template and using {% extends %} inside the include.

cheers,
Jonathan

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Suggestion for improvement to template block/extends tags

[Jonathan Slenders]

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 in the parent template need to be chosen when several have
the same name. (You'd say the most inner block, but that's not obvious
-- I think.)

I once wrote a {% decorate %} template tag for a little similar
behaviour.
https://github.com/citylive/django-template-tags/blob/master/src/django_template_tags/templatetags/decorate.py

That would become:

template.html:
{% decorate (either "a.html" or "b.html") %}
middle
{% enddecorate %}


b.html:
{% decorate "a.html" %}
left {{ decorator.content }} right
{% enddecorate %}

a.html:
first {{ decorator.content }} last

Hope that helps.
I once tried to get this into django trunk, but did not yet got
accepted.


On 29 avr, 02:11, amagee  wrote:
> I sometimes run into a situation where I want a template to be able to
> extend from one of a set of possible base templates, which I achieve
> by passing a "base_template" variable in the context to the {% extends
> %} tag.  Where this gets stuck, though, is if one of the possible
> bases extends one of the other possible bases.
>
> For example:
>
> base_a.html:
> first {% block content %}{% endblock %} last
>
> base_b.html
> {% extends "base_a.html" %}
> {% block content %}left {% ??? %} right{% endblock %}
>
> template.html
> {% extends (either "base.a.html" or "base_b.html") %}
> {% block content %}middle{% endblock %}
>
> I'd like to be able to code template.html so that if it extends
> base_a.html, the result is "first middle last", but if it extends
> "base_b.html", the result is "first left middle right last".
>
> I _think_ it would make sense to implement this with an improvement to
> the semantics of the {% block %} tag, starting by allowing nested tags
> with the same name.
>
> If base_b.html were:
> {% extends "base_a.html" %}
> {% block content %}left {% block content %}{% endblock %} right{%
> endblock %}
>
> Then the {% block content %} in template.html could override the
> _inner_ block in base_b.html.  I think this behaviour is pretty
> logical and consistent, unless I've missed something.  I've hacked
> around a bit with loader_tags.py but I'm finding it quite difficult to
> get what I want with my limited understanding of how it works.
>
> Do people think this idea makes sense?  Is it worth taking the time to
> write a patch for it?

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Fixing makemessages for Javascript

[Jonathan Slenders]

Hi Lukasz,

It does not yet generate .po files. While I haven't yet had any plans
for doing this, it's not really complex at all to make this possible
through the preprocessor.

What is currently does, is parsing and processing templates and
external css/js files. It does a lot of optimizations in order to gain
better performance at runtime, and one of the optimizations is to
preprocess all the translations.

Currently {% trans %} and {% blocktrans %} are preprocessed, even with
support for variables and {% plural %}. HTML, javascript and CSS are
also parsed, so now it's not too much work to preprocess gettext() in
javascript files as well.

The output is a 'cache' directory where the processed templates are
stored (one subdir for each language), and a cache directory for the
media/static files.

This would make using gettext() for internal javascript files instead
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 <lreku...@gmail.com> wrote:
> On 19 April 2011 15:35, Jonathan Slenders <jonathan.slend...@gmail.com> wrote:
>
>
>
> > Basically, when this works, the i18n catalog for javascript is no
> > longer required, even for external files.
> >https://github.com/citylive/django-template-preprocessor
>
> Could you elaborate on that ? How does your application help me handle
> client-side translations ?
>
> --
> Łukasz Rekucki

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Fixing makemessages for Javascript

[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 the gettext string before
doing the translation, and escape it again afterwards.


I'm asking this because I'm going to implement gettext preprocessing
in the template preprocessor and I'd like all implementations to be
compatible.
Basically, when this works, the i18n catalog for javascript is no
longer required, even for external files.
https://github.com/citylive/django-template-preprocessor

cheers,
Jonathan


On 18 avr, 00:14, Ned Batchelder  wrote:
> On 4/15/2011 12:40 PM, Russell Keith-Magee wrote:
>
>
>
>
>
>
>
> > On Fri, Apr 15, 2011 at 9:25 PM, Ned Batchelder  
> > wrote:
> >> On 4/14/2011 11:40 PM, Russell Keith-Magee wrote:
>
> >> Keep in mind that the proposal is not to include Babel, but to depend on it
> >> as a prerequisite, which means we are stuck in the same situation we are
> >> with gettext: it can change independently of Django, and new versions can
> >> introduce new bad behavior.  That's one of the reasons we have a bad 
> >> problem
> >> today: gettext changed from 0.17 to 0.18, and exacerbated the hack.
> > This is true. However, what you're proposing is, IMHO, a slightly
> > worse situation.
>
> > Babel is a self contained tool. Assuming it work as advertised (and
> > I'll grant that is a big and important assumption), it is a self
> > contained body of code. It is a dependency, but as long as it
> > continues to work as advertised, we're fine. We're only dealing with
> > it's advertised interface, and working with that interface in the way
> > it was intended to be worked with.
>
> > On the other hand, gettext is also a dependency, and gettext can also
> > change between releases -- but we're not using it as intended. We're
> > bending the Perl parser (or, in your case, the C parser) in strange
> > and unusual ways to do something it wasn't originally intended to do.
> > Something completely innocuous can change in gettext, and the
> > follow-on effect to us can be huge because we've built our castle on
> > an unstable foundation.
>
> I'm not much concerned that the C parsing in gettext will change
> significantly, but I take your point, it certainly could change behind
> our backs and we could be broken again.
>
>
>
>
>
>
>
>
>
> > The maintenance issue is the critical part here. My hesitation isn't
> > just to do with the suitability of your code *right now*. It's to do
> > with the fact that once we adopt the code into trunk, we are to
> > agreeing to maintain it. Bits don't rot, but gettext has already
> > demonstrated that it changes between versions, so it's reasonable to
> > assume that when gettext 0.19 is released (whenever that happens),
> > we'll need to make changes to our Javascript parser. By taking on the
> > lexer, we're absorbing into Django a whole bunch of project
> > responsibility that frankly, I'd rather we didn't have.
>
> >> Babel
> >> has the advantage that it is pure Python, so it is both more installable
> >> than gettext, and is more readable for us.  It also has the advantage that
> >> it isn't based on a hack, but that doesn't mean it performs flawlessly.
>
> >>> If the proposed patch was leaning on a well established lexer, or was
> >>> a simple configuration change (i.e., "treat it as C, not Perl") that
> >>> could be quickly demonstrated to fix a bunch of problems without
> >>> introducing any obvious new problems, I'd be all in favor of it as a
> >>> temporary solution. But that's not what is on the table -- it's a
> >>> complex body of code that we're proposing to evaluate, introduce,
> >>> maintain, and potentially deprecate very quickly.
>
> >> While the patch I've submitted is certainly larger than a configuration
> >> change, and is not a well-established lexer, I have "quickly demonstrated
> >> that it fixes a bunch of problems without introducing any obvious new
> >> problems", or at least, no one has come forward with a new problem.  I've
> >> paid a bounty on Stack Overflow for people to find problems in the lexer
> >> itself, which they have done, and those problems have been fixed.
> > That sort of thing evidence certainly works in your favor -- I wasn't
> > aware that this sort of testing had taken place.
>
> >>> I'm happy to be proven wrong on any of the points mentioned here --
> >>> for example, if someone can provide some mechanism that independently
> >>> demonstrates the robustness of the Javascript lexer, or evidence that
> >>> the risk of regressions is low. However, absent of such evidence, I'm
> >>> inclined to side with Jannis and concentrate our efforts on Babel --
> >>> especially if, as Jannis suggests, a Babel-based solution isn't that
> >>> much work and could be knocked off 

Re: DDN: #2594 (Template system whitespace) may cause blocktrans issue

[Jonathan Slenders]

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 the actual output.) I understand
that in most cases, it's ugly to have the indentation and leading/
trailing whitespace in the msgid, but it's not always appropriate to
strip these whitespace characters.

Personally, I prefer more explicit whitespace control [1].

Anyway, I don't know much about this subject

[1] http://jinja.pocoo.org/docs/templates/#whitespace-control

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: GSoc : Templates Compilation

[Jonathan Slenders]

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 "self" reference, and any-through-iterator is very fast, as
it's native python code (probably implemented in C). And lazy
evaluating.

It's challenging to understand your code. Maybe it's easier if you
explain in words-only how you want to implement inheritance.

-

My approach would be like this


For a template called 'x', create a dictionary 'x' with maps the block
names for this template to a func with it's matching implementation
code.
Somehow, a method render_block(name) should be made available. So when
a blocks are nested, one block should be able to call
render_block(other_name). The render_block method should do a lookup
in the dictionary for a block with this name, and call it.

Dynamic inheritance can easily be realized by replacing key/value
pairs in this dict by other implementations. Pass the original
implementation to the new implementation as an additional function
parameter. (As a curry.)

I guess it's fast, and can be cached in memory. For each rendering,
only a copy of the required template dictionaries have to be made.
(Not even a deep copy.)

---

Cheers,
Jonathan

-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: GSoc : Templates Compilation

[Jonathan Slenders]

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 to compile, you really want to optimize every possible detail.


On Mar 31, 6:00 pm, Andrey Zubko  wrote:
> ...
>     def super(self,key):
>         if len(self._levels) > 1 :
>             for level in xrange(1,len(self._levels)) :
>                 if self._levels[level].has_key(key) :
>                     return self._levels[level][key]
>         else :
>             if self._levels[0].has_key(key) :
>                 return self._levels[key]   ###  You mean:  return 
> self._levels[0][key]
>             else :
>                 return ""


Maybe turn it into this:

>     def super(self,key):
> levels = self._levels
>         if len(levels) > 1 :
> iter = levels.__iter__()
> iter.next() # Ignore first item
> for level in iter:
>                 if level.has_key(key) :
>                     return level[key]
>         else :
>             return levels[0].get(key, "")


Now you have only one lookup in 'self', half the amount of index
operators (has_key counts as index operator), no additional xrange
iterator, and only one call of "len". Gaining probably twice the
speed.


But is it really necessary to use classes and instance methods instead
of just plain methods in a module? A template should be stateless. (we
have render_context for the state when required.) Classes always have
overhead compared to methods.




-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: GSoc : Templates Compilation

[Jonathan Slenders]

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 following
  > date(context.variable or "Default value"),"Y-m-d")
faster than this?
  > date(default(resolve(context,variable),"Default value"),"Y-m-d")


P.S. I like the cleanness of adding an (optional?) compile method to
every Node-derived class.
But on the other hand, I would like to see Django move to a more end-
user-friendly way of defining custom template tags. A way which does
not involve any knowledge of the template parser/interpreter/compiler.
Of course, that could also be build upon the first.



-- 
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-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.