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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
