Re: Reversing translated urls in templates

[Jannis Leidel]

On 24.06.2011, at 23:52, Florian Apolloner wrote:

> I would like to get some feedback on 
> https://code.djangoproject.com/ticket/16332
> Jacob suggested that the standard url-tag should take a lang argument
> so we don't need an extra tag (okay, his actual concern was the
> dislike of the name i18n_url ;)). I would like that idea too, but I am
> somewhat worried about the implications; eg it would break as soon as
> someone already has "lang" as param in his urlconf and using a
> parameter like __lang isn't that nice either…
> 
> Any thoughts on this?

As I said initially when we discussed this on IRC, I believe a "i18n_url" is 
good enough
and would fit well with the other i18n related template tags.

Besides the ambiguity of a potential keyword argument "lang", I'd like to 
mention that
we specifically chose to use "i18n_patterns" as the name for the function that 
returns
i18n-enabled URL patterns to be explicit about when a URL should be translated. 
I believe
this pattern should also be applied to the template tag which a user might use 
to point to
one of those translatable URLs.

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: Form Rendering API Proposal

[Bruno Renié]

Hi all,

On Fri, Jun 24, 2011 at 12:38 PM, Gregor Müllegger  wrote:
> Hi Jacob,
>
> 2011/6/23 Jacob Kaplan-Moss :
>> Hi Idan et al. --
>>
>> Thanks for putting this all together!
>>
>> In general, I like this a lot, and I'm always going to defer to the
>> eyes of someone like Idan who spends more time wrangling templates
>> than I do. So I like the general gist, and I most don't mind the {%
>> formconfig %} business.
>>
>> However, I do have a few concerns:
>>
>> 1. Performance: it looks, to me, like rending a basic form is going to
>> cause dozens of template includes and dozens of sub-renders (the form
>> loads a form template which loads row templates which load widget
>> templates). That's dozens of disk hits, and a lot of overhead for form
>> rendering. I worry about this overhead a lot. Django's performance has
>> slipped lately, and I'm really afraid this'll make things a lot worse.
>>
>> So I'm going to need to see some benchmarks -- particularly in how a
>> simple {% form myform %} compares to {{ form.as_* }}.
>>
>> The wrong performance benchmarks could result in a veto from me; this
>> is important.
>
> Unfortunatelly we don't have any implementation yet, except of what Bruno did
> with floppyforms, what we can benchmark. But I think we could minimize disk
> hits or template-loader work by caching the rendered templates ourself. For a
> form with many fields it's very likely that most of them use the same row
> level template, so we can reuse this a couple of times during the rendering. I
> will do my best to make things as fast as possible. Benchmark was not yet part
> of my GSoC timeline but I agree that this should have a high priority.

Someone did a couple of benchmarks to measure the performance impact
of my patch (#15667, the template-widgets implementation aka
django-floppyforms). There is some slowdown, the question is whether
it's acceptable or not, and where's the limit. If you have simple
forms, they'll render in 6 milliseconds instead of 3.5. However, with
fields with lots of choices, this gets much worse. Something that
takes 32 milliseconds with the current forms implementation can take
almost 200 milliseconds to render if it's done in the templates. The
biggest part of this time is spent actually rendering the templates,
not loading them. So template caching helps but only to a limited
extent.

Also see on the ticket page, there are a couple of pretty graphs that
show exactly where time is spent. For instance, 12% of the rendering
time is spent doing isinstance() calls, that's part of the template
rendering logic.

I did the same benchmarks with pypy, and the results are interesting.
Raw results are here, for some context see the files attached to the
ticket:

http://dpaste.com/hold/558425/

So, currently I see how it can be a problem to have this as the only
widget rendering system. I don't think it's worth maintaining both
implementation (the current one and the template one) with ways to
switch from one way to another, it's going to be too much of a burden
to maintain.

When the template language gets faster, maybe we can integrate my
patch. The question is, what slowdown is acceptable? Or are we
expecting a speedup? With jinja2, widget rendering is actually
*faster* using templates than using the current string-based
implementation but I'm not sure we can go this far with django
templates. So:

* We need faster templates for this to land in trunk
* We need pypy :)
* If you want template-base widgets *now*, use django-floppyforms.
* If you want to use the new forms / templates API as soon as it's
done… how do you do it? Is it going to be packaged as an app, as a
patched version of django?

That being said, I really like the design work that's been done and I
look forward to trying it.

-Bruno

> However based on the feedback I got on djangocon and on the mailinglist yet,
> the anticipation for this feature is really big. And we won't make code slower
> that already exists. You only get a bit slower form rendering if you are going
> to use the new mechanics, but you trade that for a much more flexible and
> faster template designing. And as Benoît described in the current thread: Most
> designers already use something like the proposal suggests but with a custom
> {% include %} hierachy. Introducing a "special" syntax can only open up the
> possibilities for performance tweaking.
>
>>
>> 2. Verbosity: There's a lot of tags (well, 4, but that's a lot to me)
>> wall-of-code stuff like
>> https://github.com/idangazit/formrendering/blob/master/djangocon_sketch.html#L62-83
>> doesn't particularly give me the warm fuzzies. I think  part of the
>> problem is that all the tags are `form*` which makes for a bit of
>> "bork bork bork" there.
>>
>> I think it might be possible to simplify things somewhat here, so
>> here's my rough thoughts:
>>
>> * Keep {% form %} -- it's obvious.
>> * Rename {% formfield %} to {% field %} -- it won't conflict, and it's
>> (fairly) obvious we're talking 

Re: Reversing translated urls in templates

[maxk]

What do you think about something like below

  {% url viewname k1=v1, k2=v2 with lang=lang %}

?

On Jun 25, 12:52 am, Florian Apolloner  wrote:
> Hi,
>
> I would like to get some feedback 
> onhttps://code.djangoproject.com/ticket/16332
> Jacob suggested that the standard url-tag should take a lang argument
> so we don't need an extra tag (okay, his actual concern was the
> dislike of the name i18n_url ;)). I would like that idea too, but I am
> somewhat worried about the implications; eg it would break as soon as
> someone already has "lang" as param in his urlconf and using a
> parameter like __lang isn't that nice either…
>
> Any thoughts on this?
>
> Cheers,
> Florian

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

[Florian Apolloner]

On Jun 25, 11:58 am, Jannis Leidel  wrote:
> As I said initially when we discussed this on IRC, I believe a "i18n_url" is 
> good enough
> and would fit well with the other i18n related template tags.

Jupp, I just wanted to here if someone else had different feelings
about it.

> I believe
> this pattern should also be applied to the template tag which a user might 
> use to point to
> one of those translatable URLs.

Agreed, I leave the patch like it's now. Though I am still open for
suggestions on cleaning up the code duplication.

Cheers,
Florian

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

"c" date formating and Internet usage

[Yohan Boniface]

 Hi,

In Django's documentation, the 2 following points are mentionned [1]:

- About date formating:

"Uses the same format as PHP's date() function (http://php.net/date) with
some custom extensions."

- About the specific "c" format:

"ISO 8601 Format." e.g. : 2008-01-02T10:30:00.000123

As we can see in the example, the ouput of the "c" format does not provide
the time zone information (for example : +02:00).

Firstly, this is in contradiction with how PHP handles the "c" format : PHP
does provide the time zone information (their documentation uses
"2004-02-12T15:19:21+00:00" as the example for the "c" format [2]).
Therefore, at the very least Django's documentation is innacurate.

Secondly, even if the ISO 8601 standard allows many date formats, the
Internet usage is strongly oriented towards the use of the extended format
with time zone (for e.g. 2008-01-02T10:30:00.000123+02:00). In particular:

- In current HTML5 editor's draft [3], the W3C makes the time-zone
offset mandatory for datetimes. A W3C note about the issue was also
published. [4]

- In their Sitemap protocol documentation, Google asks for the time-zone
offset in datetimes, following the W3C Note. [5] [6]

- The RFC 3339 says the following "the interoperability problems of
unqualified local time are deemed unacceptable for the Internet." [7]
Furthermore, it specifically mentions that date-time should be exprimed with
the timezone offset. [8]

I suggest that Django follows this usage and modifies its handling of this
format. However, since this clearly has backward compatibility issues, I'd
like to have a discussion about this before proposing a patch.

Thanks,

Yohan

[1] 
https://docs.djangoproject.com/en/1.3/ref/templates/builtins/
#date 

[2] http://php.net/date 

[3] 
http://dev.w3.org/html5/spec/common-microsyntaxes.html
#valid-global-date-and-time-string

[4] http://www.w3.org/TR/NOTE-datetime

[5] 
http://www.sitemaps.org/protocol.php
#lastmoddef 

[6] 
http://www.google.com/support/webmasters/bin/answer.py?hl
=en&answer
=74288&from
=42738&rd
=1

[7] 
http://www.apps.ietf.org/rfc/rfc3339.html
#sec-4.4 

[8] 
http://www.apps.ietf.org/rfc/rfc3339.html
#sec-5.6 

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