Re: Newline stripping in templates: the dnl way
Jonathan French wrote:
> Let me make sure I've got this right --- The situation being discussed is
> not where whitespace is insignificant and can be stripped, but where
> whitespace is important and you want to control the exact amount of it,
> e.g. plain text emails. In this case, just using stripwhitespace is not
> enough. Right?
Yes, that is the main problem.
Django templates are useful (and used) for all sorts of text-based
formats. For some of these, an exact control over whitespace is needed
throughout the entire file (eg. text/plain), while for others, control
is needed in some sensitive places (eg. element attributes in html and
xml, which according to standars are not allowed to contain literal
newlines.)
The only option currently available to control whitespace is *not to
use any* for the template syntax itself, in effect writing long one-
liners. The admin site contains several examples of such:
Yes, in this case whitespace could be added between the class="" and
id="" attributes, but the main issue remains there.
Multiline comments {# #} and/or generic multiline tags would offer a
more workable alternative than the present situation, allowing for
syntax-only whitespace in templates. But they admittedly suffer from
some serious ugliness and "denaturation" of Django templates.
After reading all the above, I can see the arguments against this:
http://groups.google.com/group/django-developers?hl=en.
Re: Newline stripping in templates: the dnl way
On Feb 27, 1:01 pm, Tobia wrote:
> After reading all the above, I can see the arguments against this:
>
> if forloop.last
> %} empty-form last-related{%
> endif
> %}" id="{{
> ...
>
> Ugh!!
Agreed. Seeing that just changed me from +1 to -0 for multiline tags.
Although the multi-line comment syntax isn't that bad, it is at least
clear what it does and why.
Now that I look at it, the main problem is that you want the
appear to be on one line in the HTML. So, it should be one-liner in
the template too, or otherwise it will look strange. However, dealing
with div tags isn't the hard case, it is the email template. Django
doesn't have a good answer for that. Multi-variable include/with/
blocktrans tags are a problem too.
When reading the latest template-related threads on this list it is
pretty clear that there is no right answer for template design
philosophy questions. For example I use mainly Jinja2 for two reasons.
I need to generate largish reports, and Jinja2 beats Django's template
engine in performance by an order of magnitude. In addition, Jinja's
design philosophy fits my needs better than Django's. But, I do not
claim Jinja2 is the right answer for everybody.
We will just need to accept that it is impossible to create a template
language that fits everybody's needs perfectly. If you want something
different, use something different. I think good ideas how to make
life easier for external template engine users are welcome.
- Anssi
--
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: Revisiting multiline tags
On 2/26/2012 12:12 AM, Yo-Yo Ma wrote:
After Ned's message, I'm -0, because while I'm not fond of multi-line
tags, I cannot offer a good alternative when it comes to multi-line
"with" tags.
On Feb 25, 6:48 pm, Ned Batchelder wrote:
On 2/24/2012 11:55 PM, Yo-Yo Ma wrote:> I'm -1 on this for s specific reason;
If you need multiple lines for a
tag, you're doing it wrong.
import this
This would be far more helpful feedback if you would take the examples
of too-long tags presented in this thread, and show the "right" way to
do it.
--Ned.
While I'm glad to see people being open to changing their minds, it
worries me that none of the "one-line tag" aesthetes have spoken up to
explain how they would deal with the unwieldy constructions that started
this thread. In fact, so far two people have changed their minds when
actually grappling to come up with an answer.
What is the right way to do this:
{% trans with
varname=myobject.proprety1
someothervar=myobject.some.other_property
yetanothervar=myotherobject.with_a_painfully_long_method_name
"Even with line-wrap, it's a pain to read on a single line."
%}
or
{% blocktrans with originator=entry.originator|get_really_full_name:"mailto"
link=entry.get_metadata.link task_id=entry.task.id
process_name=entry.task.process_class|contenttype_name %}
Powers-that-be declaring, "X is ugly and won't happen" is inevitable,
but we should be able to extend the answer with "and Y is the way to do
it better?"
--Ned.
--
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.
override_settings with dynamic model creation
Hi, all Previously, I create a simple TestCase which call ``syncdb`` command in ``pre_setup`` method to create tables of apps which is only required for testing (https://gist.github.com/ 1600883). And also, I found https://github.com/edavis/django-override-settings which is really useful to override settings in tests thus I pulled request to enable dynamic model creation with that ``override_settings`` (https://github.com/edavis/django-override- settings/pull/1) But I found that ``override_settings`` is available in dev version of django. So I just wonder that if official django's ``override_settings`` support dynamic model creation. It is really useful to test own fields app because most of time the fields app required some models which have that field (and the "some models" should not be in "INSTALLED_APPS" for using the field). Thanks. -- 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: override_settings with dynamic model creation
Hi, On Monday, February 27, 2012 2:53:37 PM UTC+1, Alisue wrote: > > But I found that ``override_settings`` is available in dev version of > django. So I just wonder that if official django's > ``override_settings`` support dynamic model creation. ``override_settings`` does exactly what the name says: It overrides settings -- there is nothing special done for models etc, it's just a convenient way to change settings and restore them back later on. Cheers, Florian -- 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/-/cnhgw38Z9EMJ. 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.
Tickets #15124 and #4102
#15124 - can a committer please look at this before 1.4 hits? It got and then lost RFC for mysterious reasons. #4102 - This thing is a beast. It was "Accepted" 18 months ago, but I would bet against it ever landing in trunk. Someone should take a serious look and, if necessary, shoot it in the head (wontfix) or euthanize it (Someday/Maybe) before people spend more time on patches. Andrew -- 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.
Mobile Login????
Hey, has anyone developed a mobile login? i'm having issues. When i load the login page into a for my mobile app. It wont work. But if i redirect it to webbrowser. it works. I'm still a couple months new with django. Any help would be appriacted. thanks -- 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: Mobile Login????
On 02/27/2012 02:24 PM, relihkcin wrote: Hey, has anyone developed a mobile login? i'm having issues. When i load the login page into a for my mobile app. It wont work. But if i redirect it to webbrowser. it works. I'm still a couple months new with django. Any help would be appriacted. thanks Please elaborate on "it won't work." There's not much anyone can do but guess otherwise. Error messages and tracebacks are preferred. Considering it works in a Web browser, it doesn't sound like Django has a problem at all. My only random guess is some kind of CSRF issue, but I don't have any detail to support 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: Mobile Login????
You've mailed the django-developers list which is for development *of Django itself*. The proper mailing list about *using* Django is django-users. Please send this message to django-users unless you're proposing a change to Django. http://groups.google.com/group/django-users On Mon, Feb 27, 2012 at 11:24 AM, relihkcin wrote: > Hey, has anyone developed a mobile login? i'm having issues. When i > load the login page into a for my mobile app. It wont work. But > if i redirect it to webbrowser. it works. I'm still a couple months > new with django. Any help would be appriacted. thanks > > -- > 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. > -- 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: Tickets #15124 and #4102
On Feb 27, 9:05 pm, Andrew Badr wrote: > #15124 - can a committer please look at this before 1.4 hits? It got > and then lost RFC for mysterious reasons. > > #4102 - This thing is a beast. It was "Accepted" 18 months ago, but I > would bet against it ever landing in trunk. Someone should take a > serious look and, if necessary, shoot it in the head (wontfix) or > euthanize it (Someday/Maybe) before people spend more time on patches. I happened to just post a comment to ticket 4102. The way forward is throwing out automatic changed field tracking and just implementing what the ticket was originally about: .save(save_fields=['somef']), which would then update field somef. That should be pretty easy to implement, and it would be useful both as-is and would also allow third-party projects to implement .save() which updates only changed fields. More details in the ticket. Is anybody against the idea of "update only these fields" kwarg to .save()? - Anssi -- 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: Tickets #15124 and #4102
On Feb 27, 12:14 pm, Anssi Kääriäinen wrote:
> I happened to just post a comment to ticket 4102. The way forward is
> throwing out automatic changed field tracking and just implementing
> what the ticket was originally about: .save(save_fields=['somef']),
> which would then update field somef. That should be pretty easy to
> implement, and it would be useful both as-is and would also allow
> third-party projects to implement .save() which updates only changed
> fields. More details in the ticket.
>
> Is anybody against the idea of "update only these fields" kwarg
> to .save()?
>
> - Anssi
You're right, my OP was too general. The explicit approach is
reasonable, and it's what the ticket was originally about. That said,
the addition of select_for_update in 1.4 obviates one of the original
motivations ("avoid some minor threading issues"), but on balance it
still seems like an ok feature to add.
--
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.
Ticket and patch #17627
Can someone please review https://code.djangoproject.com/ticket/17627 for me? I think I've resolved all the outstanding issues in my latest version of the patch. Regards, Luke Granger-Brown -- 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: Mobile Login????
(2012年02月28日 04:24), relihkcin wrote: > Hey, has anyone developed a mobile login? i'm having issues. When i > load the login page into a for my mobile app. It wont work. But > if i redirect it to webbrowser. it works. I'm still a couple months > new with django. Any help would be appriacted. thanks > I'm not sure this works for you but https://github.com/lambdalisue/django-mfw -- 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: override_settings with dynamic model creation
(2012年02月28日 01:34), Florian Apolloner wrote: > Hi, > > On Monday, February 27, 2012 2:53:37 PM UTC+1, Alisue wrote: >> >> But I found that ``override_settings`` is available in dev version of >> django. So I just wonder that if official django's >> ``override_settings`` support dynamic model creation. > > > ``override_settings`` does exactly what the name says: It overrides > settings -- there is nothing special done for models etc, it's just a > convenient way to change settings and restore them back later on. > > Cheers, > Florian > So you mean that ``override_settings`` should have minimum feature and should NOT do complicated things? That makes sense but I think django SHOULD HAVE some features for creating tables dynamically in test and when user override ``INSTALLED_APPS`` that mean the user want to use that app in test (or whatever) so I suggested. Well then how do you think that django's ``TestCase`` have ``required_apps`` attribute which is used to add required apps and create tables of the apps? In that case, ``override_settings`` is not used for overriding ``INSTALLED_APPS`` and should raise warning. Thanks. Alisue -- 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.
