Re: Ticket #7817: Extending "with" and "include" tags.
On 27.10.2010, at 09:46, SmileyChris wrote:
> On Oct 27, 5:35 am, Łukasz Rekucki wrote:
>> I would like to bring this up again, because this is something that
>> would really improve readability of my templates. I'm mainly
>> interested in ticket #7817 (the include tag changes), but extending
>> "with" tag (ticket 9456) would keep things consistent.
>
> Here's a link to the ticket for the lazier ones among us:
> http://code.djangoproject.com/ticket/7817
>
> The main decision which needs to be made is one of syntax.
>
> The current proposal uses:
> {% include "name_snippet.html" with name="Joe" greeting="Hello" %}
> but this introduces an inconsistency with the {% with %} tag.
I'm feeling strongly against moving from the "value as name" to the
"name=value" notation, since I think the former is actually more readable than
the latter for the targetted audience (template authors).
> Consistency would be nice, but I think this starts to look a bit
> confusing, static tokens outnumbering actual functional ones:
> {% include "name_snippet.html" with name as "Joe" and greeting as
> "Hello" %}
Well, I think that's actually not a bad notation at all (if using the correct
order :), so for #7817 I propose the following syntax (as analogously proposed
by #9456 for {% with %}):
{% include "name_snippet.html" with "Joe" as name and "Hello" as greeting %}
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-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: contrib.staticfiles settings suggestion
On 31.10.2010, at 23:06, Ryan wrote: > I track trunk while developing new projects, and I just picked up the > new contrib.staticfiles app. I was disappointed how repetitive and > redundant the configuration is. I already have MEDIA_ROOT and > MEDIA_URL defined, so now I have to add > > STATICFILES_ROOT = MEDIA_ROOT > STATICFILES_URL = MEDIA_URL > STATICFILES_DIRS = (STATICFILES_ROOT,) Please refer to the documentation for a description of those settings. > just to get things back working like before. What is the purpose of > having both MEDIA_* *and* STATICFILES_* settings? Don't they mean the > same thing? If there's a good reason to have all these settings, can > we not have the settings I had to enter above as defaults, similar to > how MANAGERS = ADMINS by default? No, MEDIA_* and STATICFILES_* settings aren't the same, the former is for user generated content (like file uploads), the latter for general static files your site needs to work (such as css/js files). The distinction is also well described in the dev documentation. 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: staticfiles defaults broke my site
On 02.11.2010, at 03:55, Carl Karsten wrote:
> I am not completely sure what is going on, but pretty sure the new
> staticfiles thing is colliding with my existing
>
> urlpatterns += patterns('',
> (r'^static/(?P.*)$', 'django.contrib.staticfiles.views.serve',
>{'document_root': 'static/','show_indexes': True}))
>
> That used to work, now I get:
> http://0.0.0.0:8080/static/
> "Page not found: /static/" (not the typical 404 error page, which
> also seems like a bug, see below)
>
> A stupid workaround fix is:
> STATICFILES_ROOT='foo'
>
> Here is what the docs show:
> http://docs.djangoproject.com/en/dev/ref/contrib/staticfiles
> STATICFILES_ROOT Default: '' (Empty string)
> STATICFILES_URL Default: '/static/'
>
> 404 thing:
>
> It does return a 404, but not the 404 page.
That's mostly a backwards compatibility issue, since the static serve view
(called through the old AdminMediaHandler) in 1.2.X and earlier raised a blank
PermissionDenied error if accessed. I think showing here a proper 404 page
isn't a bad idea though.
> c...@dc10:~/temp$ curl -v http://0.0.0.0:8080/static/
> * About to connect() to 0.0.0.0 port 8080 (#0)
> * Trying 0.0.0.0... connected
> * Connected to 0.0.0.0 (0.0.0.0) port 8080 (#0)
>> GET /static/ HTTP/1.1
>> User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o
>> zlib/1.2.3.4 libidn/1.18
>> Host: 0.0.0.0:8080
>> Accept: */*
>>
> * HTTP 1.0, assume close after body
> < HTTP/1.0 404 NOT FOUND
> < Date: Tue, 02 Nov 2010 02:52:58 GMT
> < Server: WSGIServer/0.1 Python/2.6.6
> < Content-type: text/plain
> < Content-Length: 24
> <
> * Closing connection #0
> Page not found: /static/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #7817: Extending "with" and "include" tags.
Hi Jannis,
On Wed, Nov 3, 2010 at 3:03 PM, Jannis Leidel wrote:
> On 27.10.2010, at 09:46, SmileyChris wrote:
>
>> On Oct 27, 5:35 am, Łukasz Rekucki wrote:
>>> I would like to bring this up again, because this is something that
>>> would really improve readability of my templates. I'm mainly
>>> interested in ticket #7817 (the include tag changes), but extending
>>> "with" tag (ticket 9456) would keep things consistent.
>>
>> Here's a link to the ticket for the lazier ones among us:
>> http://code.djangoproject.com/ticket/7817
>>
>> The main decision which needs to be made is one of syntax.
>>
>> The current proposal uses:
>> {% include "name_snippet.html" with name="Joe" greeting="Hello" %}
>> but this introduces an inconsistency with the {% with %} tag.
>
> I'm feeling strongly against moving from the "value as name" to the
> "name=value" notation, since I think the former is actually more readable
> than the latter for the targetted audience (template authors).
If you are not asking real people, it's a speculation anyway.
I'm also target audience (since I write initial Django templates
structure for HTML from designer), even though I'm a programmer.
I think there are even more programmers than designers that use django
templates.
Our designer don't care at all, because she will just use any solution
to do her job.
So of two people, one voted for "=", second abstained from voting.
I think for most people "=" is slightly better than "as" because:
- All of them had math classes at school and they know "=" already.
- Not every Django template author knows English.
"Slightly" because:
- they have to spend some minutes to understand "how the tag works"
anyway, and it's much more time than they would think of "what does
'=' do here" or "what does 'as' means here".
- they just don't care. they didn't choose html, they didn't choose
css, they didn't choose django templates. it's so minor question.
Why I'm for "=":
I think, "and" + "as" are too verbose for this regular task.
They just make fast scanning through the template seeking for some
variables much harder and don't help at all.
>> Consistency would be nice, but I think this starts to look a bit
>> confusing, static tokens outnumbering actual functional ones:
>> {% include "name_snippet.html" with name as "Joe" and greeting as
>> "Hello" %}
>
> Well, I think that's actually not a bad notation at all (if using the correct
> order :), so for #7817 I propose the following syntax (as analogously
> proposed by #9456 for {% with %}):
>
> {% include "name_snippet.html" with "Joe" as name and "Hello" as greeting %}
>
>
> 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-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Bug with testing framework when not using contrib.auth
I've been using CookieStorage (for less DB usage). Us that frowned upon nowadays, in favor of the DB backend? On Nov 2, 6:26 pm, Russell Keith-Magee wrote: > On Wed, Nov 3, 2010 at 8:18 AM, David P. Novakovic > > wrote: > > This is certainly an artifact of the fact that messages recent started > > supporting anonymous messages. Previously it depended on auth. > > > I suspect you just need to open a ticket for this. > > Yes - this is oversight, not intention. > > contrib.messages depends on contrib.auth for reasons of backwards > compatibility, but unless you're using the legacy fallback storage > mechanism, that dependency doesn't exist in practice. You're the first > person to report this dependency as a practical concern. > > I suspect we'll need to crack out some of the new unittest2 features > to fix this; skipping the user_messages tests unless contrib.auth is > available. > > Yours, > Russ Magee %-) > > > > > On Wed, Nov 3, 2010 at 4:43 AM, Yo-Yo Ma wrote: > >> I have a large application that doesn't user contrib.auth, and when I > >> run `manage.py test` I get a slough of 35 errors, all of which are > >> DatabaseError: no such table: auth_user (differing Tracebacks for > >> each). I don't have any actual tests yet, just the SimpleTest that > >> comes free in tests.py. INSTALLED_APPS is: > > >> 'django.contrib.sessions', > >> 'django.contrib.messages', > >> 'myproject.myapp', # Plus 8 more custom apps omitted. > > >> With this bug, Django's testing framework is seemingly coupled to a > >> contrib app. > > >> One of the Tracebacks: > > >> == > >> ERROR: test_add > >> (django.contrib.messages.tests.user_messages.UserMessagesTest) > >> -- > >> Traceback (most recent call last): > >> File "C:\Python26\Lib\site-packages\django-trunk\django\contrib > >> \messages\tests\user_messages.py", line 13, in setUp > >> self.user = User.objects.create(username='tester') > >> File "C:\Python26\Lib\site-packages\django-trunk\django\db\models > >> \manager.py", line 138, in create > >> return self.get_query_set().create(**kwargs) > >> File "C:\Python26\Lib\site-packages\django-trunk\django\db\models > >> \query.py", line 351, in create > >> obj.save(force_insert=True, using=self.db) > >> File "C:\Python26\Lib\site-packages\django-trunk\django\db\models > >> \base.py", line 452, in save > >> self.save_base(using=using, force_insert=force_insert, > >> force_update=force_update) > >> File "C:\Python26\Lib\site-packages\django-trunk\django\db\models > >> \base.py", line 545, in save_base > >> result = manager._insert(values, return_id=update_pk, using=using) > >> File "C:\Python26\Lib\site-packages\django-trunk\django\db\models > >> \manager.py", line 195, in _insert > >> return insert_query(self.model, values, **kwargs) > >> File "C:\Python26\Lib\site-packages\django-trunk\django\db\models > >> \query.py", line 1490, in insert_query > >> return query.get_compiler(using=using).execute_sql(return_id) > >> File "C:\Python26\Lib\site-packages\django-trunk\django\db\models\sql > >> \compiler.py", line 786, in execute_sql > >> cursor = super(SQLInsertCompiler, self).execute_sql(None) > >> File "C:\Python26\Lib\site-packages\django-trunk\django\db\models\sql > >> \compiler.py", line 730, in execute_sql > >> cursor.execute(sql, params) > >> File "C:\Python26\Lib\site-packages\django-trunk\django\db\backends > >> \sqlite3\base.py", line 221, in execute > >> return Database.Cursor.execute(self, query, params) > >> DatabaseError: no such table: auth_user > > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "Django developers" group. > >> To post to this group, send email to django-develop...@googlegroups.com. > >> To unsubscribe from this group, send email to > >> django-developers+unsubscr...@googlegroups.com. > >> For more options, visit this group > >> 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-develop...@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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Bug with testing framework when not using contrib.auth
BTW, my program doesn't have any issues with gangrene. I meant "a slew of 35 errors" in my original post. Sometimes I look back at what I've typed and it amazes me. On Nov 2, 6:26 pm, Russell Keith-Magee wrote: > On Wed, Nov 3, 2010 at 8:18 AM, David P. Novakovic > > wrote: > > This is certainly an artifact of the fact that messages recent started > > supporting anonymous messages. Previously it depended on auth. > > > I suspect you just need to open a ticket for this. > > Yes - this is oversight, not intention. > > contrib.messages depends on contrib.auth for reasons of backwards > compatibility, but unless you're using the legacy fallback storage > mechanism, that dependency doesn't exist in practice. You're the first > person to report this dependency as a practical concern. > > I suspect we'll need to crack out some of the new unittest2 features > to fix this; skipping the user_messages tests unless contrib.auth is > available. > > Yours, > Russ Magee %-) > > > > > On Wed, Nov 3, 2010 at 4:43 AM, Yo-Yo Ma wrote: > >> I have a large application that doesn't user contrib.auth, and when I > >> run `manage.py test` I get a slough of 35 errors, all of which are > >> DatabaseError: no such table: auth_user (differing Tracebacks for > >> each). I don't have any actual tests yet, just the SimpleTest that > >> comes free in tests.py. INSTALLED_APPS is: > > >> 'django.contrib.sessions', > >> 'django.contrib.messages', > >> 'myproject.myapp', # Plus 8 more custom apps omitted. > > >> With this bug, Django's testing framework is seemingly coupled to a > >> contrib app. > > >> One of the Tracebacks: > > >> == > >> ERROR: test_add > >> (django.contrib.messages.tests.user_messages.UserMessagesTest) > >> -- > >> Traceback (most recent call last): > >> File "C:\Python26\Lib\site-packages\django-trunk\django\contrib > >> \messages\tests\user_messages.py", line 13, in setUp > >> self.user = User.objects.create(username='tester') > >> File "C:\Python26\Lib\site-packages\django-trunk\django\db\models > >> \manager.py", line 138, in create > >> return self.get_query_set().create(**kwargs) > >> File "C:\Python26\Lib\site-packages\django-trunk\django\db\models > >> \query.py", line 351, in create > >> obj.save(force_insert=True, using=self.db) > >> File "C:\Python26\Lib\site-packages\django-trunk\django\db\models > >> \base.py", line 452, in save > >> self.save_base(using=using, force_insert=force_insert, > >> force_update=force_update) > >> File "C:\Python26\Lib\site-packages\django-trunk\django\db\models > >> \base.py", line 545, in save_base > >> result = manager._insert(values, return_id=update_pk, using=using) > >> File "C:\Python26\Lib\site-packages\django-trunk\django\db\models > >> \manager.py", line 195, in _insert > >> return insert_query(self.model, values, **kwargs) > >> File "C:\Python26\Lib\site-packages\django-trunk\django\db\models > >> \query.py", line 1490, in insert_query > >> return query.get_compiler(using=using).execute_sql(return_id) > >> File "C:\Python26\Lib\site-packages\django-trunk\django\db\models\sql > >> \compiler.py", line 786, in execute_sql > >> cursor = super(SQLInsertCompiler, self).execute_sql(None) > >> File "C:\Python26\Lib\site-packages\django-trunk\django\db\models\sql > >> \compiler.py", line 730, in execute_sql > >> cursor.execute(sql, params) > >> File "C:\Python26\Lib\site-packages\django-trunk\django\db\backends > >> \sqlite3\base.py", line 221, in execute > >> return Database.Cursor.execute(self, query, params) > >> DatabaseError: no such table: auth_user > > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "Django developers" group. > >> To post to this group, send email to django-develop...@googlegroups.com. > >> To unsubscribe from this group, send email to > >> django-developers+unsubscr...@googlegroups.com. > >> For more options, visit this group > >> 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-develop...@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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Potential mistake in docs.
In the related_name docs ( http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.ForeignKey.related_name ) you read about how you must specify a related_name for any foreign key in an abstract base class. This doesn't seem to be true in practice (I'm using trunk from a week ago, or so). The models I have that subclass my ABM work just fine, and no warnings are raised during validation. This might simply be a change that went documented. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #7817: Extending "with" and "include" tags.
On 03.11.2010, at 12:01, burc...@gmail.com wrote:
> Hi Jannis,
>
> On Wed, Nov 3, 2010 at 3:03 PM, Jannis Leidel wrote:
>> On 27.10.2010, at 09:46, SmileyChris wrote:
>>
>>> On Oct 27, 5:35 am, Łukasz Rekucki wrote:
I would like to bring this up again, because this is something that
would really improve readability of my templates. I'm mainly
interested in ticket #7817 (the include tag changes), but extending
"with" tag (ticket 9456) would keep things consistent.
>>>
>>> Here's a link to the ticket for the lazier ones among us:
>>> http://code.djangoproject.com/ticket/7817
>>>
>>> The main decision which needs to be made is one of syntax.
>>>
>>> The current proposal uses:
>>> {% include "name_snippet.html" with name="Joe" greeting="Hello" %}
>>> but this introduces an inconsistency with the {% with %} tag.
>>
>> I'm feeling strongly against moving from the "value as name" to the
>> "name=value" notation, since I think the former is actually more readable
>> than the latter for the targetted audience (template authors).
>
> If you are not asking real people, it's a speculation anyway.
Heh, so you are saying my gut feeling is speculative, I'm not sure what to
respond to that. In any case, you are implying that I'm not "real people" --
what ever that is -- I can assure you that I use templates as a programmer and
a designer. In case you think "we programmers can do whatever we want, the
designer won't even notice the api change", I have to admit the designer in me
feels a little insulted.
It does make a difference to use a mathamatical sign in a commonly used aspect
of the template language than prose. Note, I'm not saying that I disagree with
getting rid of warts (#7817, #9456), but actually proposed a compromise that
was already mentioned by another core dev.
>>> Consistency would be nice, but I think this starts to look a bit
>>> confusing, static tokens outnumbering actual functional ones:
>>> {% include "name_snippet.html" with name as "Joe" and greeting as
>>> "Hello" %}
>>
>> Well, I think that's actually not a bad notation at all (if using the
>> correct order :), so for #7817 I propose the following syntax (as
>> analogously proposed by #9456 for {% with %}):
>>
>> {% include "name_snippet.html" with "Joe" as name and "Hello" as greeting %}
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Bug with testing framework when not using contrib.auth
On Wed, Nov 3, 2010 at 1:43 PM, Yo-Yo Ma wrote: > I've been using CookieStorage (for less DB usage). Us that frowned > upon nowadays, in favor of the DB backend? There is no "db" backend for messages, there is only a "legacy" backend, which, as the name suggests, is for legacy applications -- applications that used Django's older (pre 1.2) user-messages table and need to migrate to using the Django-1.2 messages framework. There is a db backend for sessions, but the choice of session backend is independent of the choice of messages backend. The "right" solution is entirely up to your own requirements; Django doesn't discourage the use of any of the options it provides, other than to say that the legacy backend only exists for backwards compatibility purposes. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Potential mistake in docs.
On Wed, Nov 3, 2010 at 3:06 PM, Yo-Yo Ma wrote: > In the related_name docs ( > http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.ForeignKey.related_name > ) you read about how you must specify a related_name for any foreign > key in an abstract base class. This doesn't seem to be true in > practice (I'm using trunk from a week ago, or so). The models I have > that subclass my ABM work just fine, and no warnings are raised during > validation. This might simply be a change that went documented. It's not quite as simple as that; you *should* specify a related_name for any foreign key on an abstract base class, but it will only become a problem when you have two concrete subclasses of the abstract base. If you think about what will happen with backreferences on the concrete subclasses, it should be fairly obvious why this is a problem. If you will only ever have one concrete subclass, you won't see this problem, but as a defensive measure for the general case, the advice given by the documentation is sound. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #7817: Extending "with" and "include" tags.
On Wed, Nov 3, 2010 at 5:18 PM, Jannis Leidel wrote:
> On 03.11.2010, at 12:01, burc...@gmail.com wrote:
>
>> Hi Jannis,
>>
>> On Wed, Nov 3, 2010 at 3:03 PM, Jannis Leidel wrote:
>>> On 27.10.2010, at 09:46, SmileyChris wrote:
>>>
On Oct 27, 5:35 am, Łukasz Rekucki wrote:
> I would like to bring this up again, because this is something that
> would really improve readability of my templates. I'm mainly
> interested in ticket #7817 (the include tag changes), but extending
> "with" tag (ticket 9456) would keep things consistent.
Here's a link to the ticket for the lazier ones among us:
http://code.djangoproject.com/ticket/7817
The main decision which needs to be made is one of syntax.
The current proposal uses:
{% include "name_snippet.html" with name="Joe" greeting="Hello" %}
but this introduces an inconsistency with the {% with %} tag.
>>>
>>> I'm feeling strongly against moving from the "value as name" to the
>>> "name=value" notation, since I think the former is actually more readable
>>> than the latter for the targetted audience (template authors).
>>
>> If you are not asking real people, it's a speculation anyway.
>
> Heh, so you are saying my gut feeling is speculative, I'm not sure what to
> respond to that. In any case, you are implying that I'm not "real people" --
> what ever that is -- I can assure you that I use templates as a programmer
> and a designer. In case you think "we programmers can do whatever we want,
> the designer won't even notice the api change", I have to admit the designer
> in me feels a little insulted.
>
> It does make a difference to use a mathamatical sign in a commonly used
> aspect of the template language than prose. Note, I'm not saying that I
> disagree with getting rid of warts (#7817, #9456), but actually proposed a
> compromise that was already mentioned by another core dev.
I also don't disagree, just not completely agree with your reasoning.
Sorry for being harsh. Just "my inner designer" gets confused when
someone calls "as" and "and" much useful for purpose of setting
variables rather than "=". Hm Maybe because HTML uses "=" for
setting attributes? :)
Consistency would be nice, but I think this starts to look a bit
confusing, static tokens outnumbering actual functional ones:
{% include "name_snippet.html" with name as "Joe" and greeting as
"Hello" %}
>>>
>>> Well, I think that's actually not a bad notation at all (if using the
>>> correct order :), so for #7817 I propose the following syntax (as
>>> analogously proposed by #9456 for {% with %}):
>>>
>>> {% include "name_snippet.html" with "Joe" as name and "Hello" as greeting %}
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Ticket #7817: Extending "with" and "include" tags.
On 3 November 2010 10:03, Jannis Leidel wrote:
> On 27.10.2010, at 09:46, SmileyChris wrote:
>
>> On Oct 27, 5:35 am, Łukasz Rekucki wrote:
>>> I would like to bring this up again, because this is something that
>>> would really improve readability of my templates. I'm mainly
>>> interested in ticket #7817 (the include tag changes), but extending
>>> "with" tag (ticket 9456) would keep things consistent.
>>
>> Here's a link to the ticket for the lazier ones among us:
>> http://code.djangoproject.com/ticket/7817
>>
>> The main decision which needs to be made is one of syntax.
>>
>> The current proposal uses:
>> {% include "name_snippet.html" with name="Joe" greeting="Hello" %}
>> but this introduces an inconsistency with the {% with %} tag.
>
> I'm feeling strongly against moving from the "value as name" to the
> "name=value" notation, since I think the former is actually more readable
> than the latter for the targetted audience (template authors).
>
>> Consistency would be nice, but I think this starts to look a bit
>> confusing, static tokens outnumbering actual functional ones:
>> {% include "name_snippet.html" with name as "Joe" and greeting as
>> "Hello" %}
>
> Well, I think that's actually not a bad notation at all (if using the correct
> order :), so for #7817 I propose the following syntax (as analogously
> proposed by #9456 for {% with %}):
>
> {% include "name_snippet.html" with "Joe" as name and "Hello" as greeting %}
My argument against this is that it's not consistent use of "as". Take
the {% url %} tag:
{% url my_view object_id=5 section="B" as my_view_url %}
There is clear separation about what is an argument to the tag and
what is being set in current scope. Now {% with %} and {% blocktrans
%} behave the same with a small difference of changing current scope.
{% with "John" as person_name %}
{# context was changed by using "as" and person_name is now availble #}
{% endwith %}
Thus I would leave {% with %} and {% blocktrans %} with this syntax as
it's intuitive and readable. The proposed change to {% include %} is a
bit diffrent. Currently, there is a way to write inclusion tags and
pass arguments to them, that usually land in the context. So my custom
inclusion tag right now will look like this:
{% show_note note "Title" %}
If we were to extend the inclusion tag shortcut to support keyword
arguments I think most people would expect it to look like this:
{% show_note note=object title="Title" %}
rather than:
{% show_note object as note and "Title" as title %}
because that's how most tags get their arguments passed. {% include %}
with proposed extensions can be considered as a inclusion_tag with a
variable template name:
{% include "foo.html" x=1 y=2 %}
It takes arguments and doesn't modify scope, so It should be
consistent with tags that do the same. The interleaving "with" keyword
could be removed not to confuse people.
--
Ł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-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Git-using core devs: preference for merge vs. rebase?
Hi Tom, On Nov 2, 12:58 pm, "Tom X. Tobin" wrote: > Do the Git-using core developers have a preference for merge vs. > rebase for updating an upstream-tracking branch? I prefer to rebase > to keep the changes in question at the branch HEAD, especially if the > branch hasn't been pushed publicly yet, but a rebase for something > that *has* been pushed means a forced overwrite is necessary, which > may trip up anyone who has already added the branch as a remote and > isn't expecting it. I understand the appeal of keeping the changes nice and linear at the head, but in practice I find merging pretty easy to deal with. With github compare view (and command-line equivalents "git diff master...branchname" and "git log master...branchname") it's still quite easy to tease out the actual changes in the branch for review. Merging also keeps commit messages accurate for long-running feature branches, and avoids the forcing hassles for anyone trying to track your branch. For something you haven't pushed in public yet, of course rebasing is fine. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Bump/question for #13956
As far as I know, the only thing still missing from the ticket is a decision as to whether there need to be documentation changes for simple tags and inclusion tags... if there need to be changes, I could try working on them. I would just need to know. Best, Stephen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Bump/question for #13956
Has supporting kwargs along with args been mentioned? I would find having both very helpful. Maybe we can lean on the work happening for the include and with tags. On Wed, Nov 3, 2010 at 10:06 AM, Stephen Burrows wrote: > As far as I know, the only thing still missing from the ticket is a > decision as to whether there need to be documentation changes for > simple tags and inclusion tags... if there need to be changes, I could > try working on them. I would just need to know. > Best, > Stephen > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Bug with testing framework when not using contrib.auth
Ok, thanks. I'm using CookieStorage for messages, so the issue may not reside only with legacy storage. Should I create a ticket for this? On Nov 3, 6:11 am, Russell Keith-Magee wrote: > On Wed, Nov 3, 2010 at 1:43 PM, Yo-Yo Ma wrote: > > I've been using CookieStorage (for less DB usage). Us that frowned > > upon nowadays, in favor of the DB backend? > > There is no "db" backend for messages, there is only a "legacy" > backend, which, as the name suggests, is for legacy applications -- > applications that used Django's older (pre 1.2) user-messages table > and need to migrate to using the Django-1.2 messages framework. > > There is a db backend for sessions, but the choice of session backend > is independent of the choice of messages backend. > > The "right" solution is entirely up to your own requirements; Django > doesn't discourage the use of any of the options it provides, other > than to say that the legacy backend only exists for backwards > compatibility purposes. > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Bug with testing framework when not using contrib.auth
On Thu, Nov 4, 2010 at 3:58 AM, Yo-Yo Ma wrote: > Ok, thanks. I'm using CookieStorage for messages, so the issue may not > reside only with legacy storage. Should I create a ticket for this? If you'd be so kind. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.staticfiles settings suggestion
On Nov 3, 4:12 am, Jannis Leidel wrote: > > No, MEDIA_* and STATICFILES_* settings aren't the same, the former is for > user generated content (like file uploads), the latter for general static > files your site needs to work (such as css/js files). The distinction is also > well described in the dev documentation. > Where is this distinction in the docs? I read over the staticfiles documentation trying to figure out how it related to MEDIA_* and it was not clear to me. I think the docs need some improving to explain the purpose of this app and the problem it is trying to solve (separation of user uploaded media and app media). It just kind of landed in trunk. It wasn't obvious to me, for example, that the dev server would continue to serve media in MEDIA_ROOT or if I had to add MEDIA_ROOT to STATICFILES_DIRS and enable the FileSystemFinder. I realize it might be too early for release notes, but that would be helpful for me at least. I'd be glad to help, but I'm still trying to figure it out. I'll try to write a blog post or a doc patch. Thanks, BN -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: It is real to add ticket #8054 to 1.3 milestone?
Hi All! Sorry for late response.
On Fri, Oct 29, 2010 at 7:47 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
> ... which is something you can already do with a callable column::
>
> class MyModelAdmin(ModelAdmin):
> def formatted_foobar(self, obj):
> return slugify(truncatewords(obj.foobar, 2))
>
>list_display = ('formatted_foobar', 'name', 'age')
>
> with the added benefit that you can do a lot more that just applying a
> template filter -- to pick a trivial example, you could conditionally
> apply *different* template filters, depending on the value of the
> attribute.
>
Yes, I know about it. Ticket #8054 is not cover this case, you need to
define a new function for this. Ticket #8054 is not about it. It's about how
you put in ModelAdmin meta data of this function related to display it in
admin change list. I'll try to explain it bellow, but now let's speak about
template filters. Most common case in change list customization is then you
need just apply some template filters to 1 model field for every model
objects. This ticket lets do it more easy. If you need more logic to render
field, you must define new callable for it of course.
The main benefits of #8054 is considerate all options related to admin
change list customization in list_display property of ModelAdmin.
It solves some little code organization problems with callable attributes.
For example, If you want customize change list header for column getting
form model method, you can use attribute short_description for it, but this
is related only for admin change list and not ever need anything else. It's
more logically to define it something in ModelAdmin and not creating new
callable or copy existing for customization needs. It's first proposed
benefits.
The second is a small refactoring of django.contrib.admin. This ticket adds
some changes to admin change list generation. Currently admin change list is
generating with a couple of template tags and most of all change list logic
considerate in this template tags. This ticket move logic of displaying
object field value and column header to special place - classes inherited
from ListColumn.
Honestly, I can't see the benefit in what you're proposing here.
> Before you spend a whole lot more time updating the patch to try and
> make and keep it trunk ready, you need to convince me (or another
> member of the core team) that the idea you're proposing is worth
> adding to trunk. Otherwise you're just going to be spending a lot of
> time maintaining a patch that won't ever get committed.
>
Hm. In this case why this ticket is on accepted triage stage and assigned on
the one from core team developers a long time?
It is my first experience to send my code in this community, this ticket was
related to my needs, and I followed only instructions from official Django
documentation.
Cheers,
Alex Kamedov
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: It is real to add ticket #8054 to 1.3 milestone?
On Thu, Nov 4, 2010 at 12:33 PM, Alex Kamedov wrote: > On Fri, Oct 29, 2010 at 7:47 AM, Russell Keith-Magee > wrote: >> Honestly, I can't see the benefit in what you're proposing here. >> Before you spend a whole lot more time updating the patch to try and >> make and keep it trunk ready, you need to convince me (or another >> member of the core team) that the idea you're proposing is worth >> adding to trunk. Otherwise you're just going to be spending a lot of >> time maintaining a patch that won't ever get committed. > > Hm. In this case why this ticket is on accepted triage stage and assigned on > the one from core team developers a long time? I can see that you have done what you have done in good faith. However, I think you have misread the tone around the ticket. The problem is that the state of a ticket in Trac can only be used as an indication, not as an absolute guide. We allow anyone to modify tickets, so just because a ticket is "accepted" doesn't necessarily mean that the idea has been accepted -- you need to pay attention to *who* has accepted the ticket. Tickets also decay over time; an idea that seemed great and was accepted a year ago may not be accepted today, because of other changes that have occurred in Django. Lastly, (and most applicable to this case), a ticket that has been partially addressed may not be updated to reflect an accurate state of the ticket. Looking at #8054 specifically: The ticket was accepted on 13 August 2008, after an initial period in design decision needed. The design discussion entirely revolves around the idea of methods/functions as list_display items, and, on 14 August 2008 (r8352), that's exactly what Brian committed. Brian followed that checkin with a comment: "Moving to post-1.0 for the API changing parts. This should be looked at with a ChangeList and templatetag refactor of the admin. Not sure when or how, but this is related." Since that time, there has been no core team member involvement or discussions. I'm not aware of any django-dev discussions about the feature. However, there have been a couple of people maintaining the original patch -- the one that Brian decided *not* to apply in the first place. Reading between the lines, this means that the ticket really isn't in an accepted state anymore -- at the very least, it's DDN, and probably wontfix. I don't know what Brian had in mind at the time, but he obviously wasn't happy with the proposed approach, and two years later, I agree. > It is my first experience to send my code in this community, this ticket was > related to my needs, and I followed only instructions from official Django > documentation. First off -- what you have encountered with this ticket isn't my idea of an ideal first contribution experience. I can see that you have done everything that the contribution guide said to do -- it's just that the contribution guide doesn't do a good job of capturing the esoteric nature of "reading" Trac tickets. In that respect, we (the core team) have failed you. I wholeheartedly apologize for that. I suppose the only practical advice I can give would be the following: * Trac isn't an absolute; the context is just as important as the literal message. You need to take into account who says things, when they said them, and the completely ambiguous who *hasn't* said things. * If you're going to engage in a big project, it helps to make sure that your idea has support first. This means getting someone to confirm that a bug is real before you spend a whole lot of time fixing the issue, and confirming that the core team currently supports a proposed feature before you implement it. These are both points that the contributions guide doesn't do a good job of reinforcing, and it probably should. Ticket #14401 is a work in progress discussing a new "contributions howto" that would cover some of the fuzzy issues around contributing to Django; I've just updated the draft text to cover the points I've raised here. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: It is real to add ticket #8054 to 1.3 milestone?
I've tried communicate with Brian via email before start discussion here. I take the email address from his github account. In email I ask he about his plans on this ticket, but don't get reply. Originally I need to add some customization to admin change list requested by my clients. It's possible with some ways with current django.contrib.admin and I've need to found of the best of them. It's not related with template tags or something related with ticket #8054. To resolve my problem I have need to know about how admin change list is rendered. I thought, reviewing Daniel's patch is a short way to understand it. I like his idea. I port his patch on more newer version of Django, share it with community via Track and after some time from unfortunately communication with Brian try to promote it here. I don't know that I spent my time on no purpose. Anyway I've successfully done all my goals and in addiction learned about how django test suit is organized. If this ticket isn't useful for Django today, so this is life. On Thu, Nov 4, 2010 at 10:35 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > The problem is that the state of a ticket in Trac can only be used as > an indication, not as an absolute guide. We allow anyone to modify > tickets, so just because a ticket is "accepted" doesn't necessarily > mean that the idea has been accepted -- you need to pay attention to > *who* has accepted the ticket. Tickets also decay over time; an idea > that seemed great and was accepted a year ago may not be accepted > today, because of other changes that have occurred in Django. Lastly, > (and most applicable to this case), a ticket that has been partially > addressed may not be updated to reflect an accurate state of the > ticket. > > Looking at #8054 specifically: The ticket was accepted on 13 August > 2008, after an initial period in design decision needed. The design > discussion entirely revolves around the idea of methods/functions as > list_display items, and, on 14 August 2008 (r8352), that's exactly > what Brian committed. > > Brian followed that checkin with a comment: "Moving to post-1.0 for > the API changing parts. This should be looked at with a ChangeList and > templatetag refactor of the admin. Not sure when or how, but this is > related." > > Since that time, there has been no core team member involvement or > discussions. I'm not aware of any django-dev discussions about the > feature. However, there have been a couple of people maintaining the > original patch -- the one that Brian decided *not* to apply in the > first place. > > Reading between the lines, this means that the ticket really isn't in > an accepted state anymore -- at the very least, it's DDN, and probably > wontfix. I don't know what Brian had in mind at the time, but he > obviously wasn't happy with the proposed approach, and two years > later, I agree. > > > It is my first experience to send my code in this community, this ticket > was > > related to my needs, and I followed only instructions from official > Django > > documentation. > > First off -- what you have encountered with this ticket isn't my idea > of an ideal first contribution experience. I can see that you have > done everything that the contribution guide said to do -- it's just > that the contribution guide doesn't do a good job of capturing the > esoteric nature of "reading" Trac tickets. In that respect, we (the > core team) have failed you. I wholeheartedly apologize for that. > > I suppose the only practical advice I can give would be the following: > > * Trac isn't an absolute; the context is just as important as the > literal message. You need to take into account who says things, when > they said them, and the completely ambiguous who *hasn't* said things. * If you're going to engage in a big project, it helps to make sure > that your idea has support first. This means getting someone to > confirm that a bug is real before you spend a whole lot of time fixing > the issue, and confirming that the core team currently supports a > proposed feature before you implement it. > > These are both points that the contributions guide doesn't do a good > job of reinforcing, and it probably should. Ticket #14401 is a work in > progress discussing a new "contributions howto" that would cover some > of the fuzzy issues around contributing to Django; I've just updated > the draft text to cover the points I've raised here. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group,
